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

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

RfD: Quotations

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

Contents

  RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 21:22 +0100
    Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:35 +0000
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 14:20 +0100
    Re: RfD: Quotations Ron Aaron <rambamist@gmail.com> - 2015-07-29 13:44 +0300
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 13:42 +0100
    Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 05:35 -0700
      Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 13:34 +0000
        Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 07:35 -0700
          Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 15:05 +0000
          Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 16:19 +0100
            Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-29 21:48 +0100
        Re: RfD: Quotations mhx@iae.nl - 2015-07-29 11:13 -0700
          Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:04 +0000
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 15:07 +0100
        Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 07:44 -0700
          Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 15:12 +0000
          Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 16:18 +0100
            Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:37 +0200
              Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 17:55 +0100
                Re: RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2015-07-29 19:51 -0500
                  Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 03:31 +0200
                    Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 19:30 -0700
                      Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 21:19 -0700
                        Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 21:37 -0700
                          Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 11:45 +0000
                            Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-30 08:07 -0700
                              Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:54 +0000
                                Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 12:48 +0100
                                  Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 05:40 -0700
                                    Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 14:46 +0100
                                      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 14:50 +0100
                                    Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 14:46 +0000
                                Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-31 13:16 -0700
                                  Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 21:49 +0100
                        Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 22:42 -0700
                        Re: RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2015-07-30 08:46 -0500
                    Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 21:40 -0700
                    Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 10:01 +0100
                      Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 12:00 +0200
                        Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 11:10 +0100
                    Re: RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2015-07-30 16:35 +0200
              Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 16:53 +0000
            Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-29 19:03 +0200
              Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 18:24 +0100
                Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 01:38 +0200
                  Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:10 +0100
                    Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 12:06 +0200
                      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 11:21 +0100
                        Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 14:00 +0200
                          Re: RfD: Quotations franck.bensusan@gmail.com - 2015-07-30 06:59 -0700
                          Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 10:53 +0100
              Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 10:35 -0700
                Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 01:45 +0200
                  Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 03:17 +0200
                    Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 19:21 -0700
                    Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 23:04 -0700
                      Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 12:38 +0200
                        Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 12:09 +0100
                          Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 13:26 +0200
                            Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 09:47 +0100
                              Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 02:51 -0700
                                Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 11:21 +0100
                  Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:11 +0100
              Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 11:36 -0700
                Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 11:37 -0700
              Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:07 +0000
                Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 16:25 +0200
            Re: RfD: Quotations mhx@iae.nl - 2015-07-29 11:16 -0700
              Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 20:27 +0100
                Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-29 21:57 +0100
                  Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 22:48 +0100
                    Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 12:34 +0100
                      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 13:00 +0100
                        Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 14:31 +0000
                        Re: RfD: Quotations mhx@iae.nl - 2015-07-31 11:32 -0700
                Re: RfD: Quotations mhx@iae.nl - 2015-07-29 21:42 -0700
                  Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:57 +0100
            Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 17:21 -0700
              Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:56 +0100
                Re: RfD: Quotations franck.bensusan@gmail.com - 2015-07-30 04:15 -0700
                  Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 12:30 +0100
                    Re: RfD: Quotations franck.bensusan@gmail.com - 2015-07-30 05:04 -0700
                      Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-30 13:07 -0700
    Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 16:52 -0700
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:53 +0100
    Re: RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-30 21:45 +0200
      Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-30 13:25 -0700
        Re: RfD: Quotations Julian Fondren <ayrnieu@gmail.com> - 2015-07-30 15:11 -0700
          Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 09:11 +0100
            Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 12:04 +0100
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 22:51 +0100
        Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-30 22:38 -0700
          Re: RfD: Quotations "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-31 02:10 -0400
          Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 09:01 +0100
            Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-01 14:59 -0700
              Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-08-01 23:36 +0100
                Re: RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 01:19 +0200
                  Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-01 18:27 -0700
                    Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-09 14:34 -0700
    Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 08:52 +0000
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 11:57 +0100
    Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 21:42 +0100
      Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 22:25 +0100
        Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 23:39 +0100
          Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-01 10:59 +0100
      Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-01 14:18 +0000
        Re: RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-01 22:10 +0200
          Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-02 05:36 +0000
            Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-03 16:40 +0100
              Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-08-03 18:02 +0100
                Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-03 20:22 +0100
              Re: RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2015-08-04 02:10 +0200
                Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-04 08:49 +0100
    Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-01 15:15 -0700

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

#41003

> Let's take the example you gave.
> 
> : bar { x y -- xt } [: ( called Q below ) x dup y + to x   + :] ;	
> 10 20 bar execute
> 
> There are the following events; BAR-COMPILE when BAR is compiled,
> Q-COMPILE when the quotation is compiled (a part of BAR-COMPILE and in
> the scope of BAR), BAR-EXECUTE when BAR is executed and Q- EXECUTE when
> the quotation is executed.
> 
> Here's the information available at each phase, and what you would need
> to do to make this scheme work.
> 
> BAR-COMPILE: X and Y addresses are known (A(X) and A(Y)), but not the
> values.
> 
> Q-COMPILE: Same information as BAR-COMPILE, since it is done in the
> context of compiling BAR. Reserve slots for X and Y (X-SLOT and Y-SLOT)
> in the execution environment for Q.
> 
> BAR-EXECUTE: X and Y now have definite values. BAR uses X-SLOT and Y-SLOT
> slots in Q to copy the values in the future execution scope for
> Q-EXECUTE.
> 
> Critically, we have to pass compile time information about locals and
> local-SLOTs (A(X), A(Y), X-SLOT and Y-SLOT) from Q-COMPILE through to
> BAR-EXECUTE. How would you propose implementing this?

This discussion is going wild. 

If you access a local variable that has gone out of scope this is undefined behaviour.
It has nothing to do with quotations. It's about the local variables.
And this doesn't have to be declared ambiguous condition. It's undefined behaviour.

Any local variable implementation that uses a frame pointer can
easily allow quotations to see outer locals. 
If you cannot accept that, better leave it off. The local support in the
forth standard is very poor anyway. What are you trying to make here is to
discuss a poor quotation implementation in relation to a poor local 
implementation. The result will be a load of ambiguopus conditions, mays
and mays not, and all the ambiguous stuff already there in the standard.

Why not concentrate on making the locals better first?
Try to get rid of the whole ambiguous stuff regarding local variables
(in corelation with the >r, r>, do loops, etc).
In my system, local variables are not influenced by >r, r> or for/next
structures (if I have had do/loops they weren't been influenced by these too).
So, it is possible.

And then, we can disscuss quotations too.

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

#41005

on 31/07/2015 10:51:44, Raimond Dragomir wrote:

> 
> This discussion is going wild.
> 
> If you access a local variable that has gone out of scope this is
> undefined behaviour. It has nothing to do with quotations. It's about
> the local variables. And this doesn't have to be declared ambiguous
> condition. It's undefined behaviour.

The discussion about "ambiguous" is the one that's been going wild for
quite a while on clf. It's unambigously nuts, and it's being driven by a
complete misunderstanding and some individuals with a "I hate the ANS
Forth standard and all its subscribers" attitude.

And now you want to invent new language. The specification does not
contain a single example of the phrase "undefined behavio[u]r". It says
"ambiguous condition: A circumstance for which this standard does not
prescribe a specific behavior". The RfD process is quite specific: "If
you want to leave something open to the system implementor, make that
explicit, e.g., by making it an ambiguous condition." 

Too many people seem to be getting hung up on their own personal
interpretation of "ambiguous", and some have decided that because
specifications are supposed to be precise and define stuff so there's no
wiggle room, ambiguous is bad. (Or, as in one notable case, if they have
an irrational dislike of what it says.)

It's not bad, on two counts. Firstly, what is meant by ambiguous is
clearly defined in the specification and RfD process. Secondly, no
specification can provide the rigour demanded by some without prescribing
the implementation and possibly getting it so tight that it's
unimplementable in the real world.

Can we move on from this please?

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

#40947

on 30/07/2015 00:45:12, Bernd Linsel wrote:
> Am 29.07.2015 um 19:35 schrieb Paul Rubin:
>> Bernd Linsel <bl1@gmx.com> writes:
>>> Why not make a compromise?  Outer words' locals...are copied into a
>>> dedicated "static variable area"...  living as long as the quotation
>>> itself... Example:
>>> : make-add-x+y   { x y -- xt }
>>>     [: { x y } x dup   y + to x  + ;] ;
>>
>> 1. I can't tell when the { x y } inside the local is supposed to shadow
>> the outer x and y.
> 
> Probably this example wasn't thought over thoroughly.
> I had in mind: When encountering { x y } in the quotation, x and y are
> taken from the parent's local frame and made 'static locals'. Perhaps
> it is clearer to require writing [: x y { x y } ...
> 
>>
>> 2. How are you supposed know when the quotation's lifetime has ended, if
>> you've passed the xt to some other word that might have saved it
>> somewhere?  Normally that's implemented with garbage collected closures,
>> but I don't think that's what you're describing.
>>
> 
> It doesn't end, except you execute FORGET or a MARKER that includes
> the quotations last definition.
> 
> I didn't want to address this problem; you do also have it with the
> proposed RfD. Otherwise the xt would have to be reference-counted or
> tracked in another way, or the quotation (and its associated data)
> must be garbage-collected.
> 
> --
> Regards
> Bernd
> 

There has bee a pretty extensive discussion of closures (as opposed to
their much simpler cousins, quotations) on this newsgroup. See
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html
for an example.

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

#40917

Bernd Linsel <bl1@gmx.com> writes:
> Outer words' locals are visible, and when referenced within the
> quotation, they are copied into a dedicated "static variable area"
> (term borrowed from C, and "static" shall be understood as in C)
> belonging to the quotation (and living as long as the quotation
> itself).

How do you know how long the quotation lives, without garbage
collection?  It is still alive if you have passed its xt to some other
function, that has saved the xt somewhere.

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

#40918

Paul Rubin <no.email@nospam.invalid> writes:
> How do you know how long the quotation lives...

Woops, sorry, ignore that, it was a redundant post.

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

#40968

Bernd Linsel <bl1@gmx.com> writes:
>Why not make a compromise?
>
>Outer words' locals are visible, and when referenced within the 
>quotation, they are copied into a dedicated "static variable area" (term 
>borrowed from C, and "static" shall be understood as in C) belonging to 
>the quotation (and living as long as the quotation itself).
>
>Subsequent changes to the variable made by the quotation don't affect 
>the parent's local, but the quotation's own 'static' copy.
>The effect is that you can pass data into a quotation at definition time 
>that is valid as long as the code without having to deal with eventual 
>'quot-sys's on the stack.

: foo { a } [: a ;] ;
5 foo constant bar1
7 foo constant bar2
bar1 execute .
bar2 execute .
3 foo constant bar3
bar1 execute .
bar2 execute .

With only one (i.e., static) instance of A for BAR1, BAR2, and BAR3,
this variant of outer locals will not be very useful.  And the little
use it may have is covered by global VARIABLEs already.

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

#40973

On 7/30/2015 3:07 PM, Anton Ertl wrote:
> Bernd Linsel <bl1@gmx.com> writes:
>> Why not make a compromise?
>>
>> Outer words' locals are visible, and when referenced within the
>> quotation, they are copied into a dedicated "static variable area" (term
>> borrowed from C, and "static" shall be understood as in C) belonging to
>> the quotation (and living as long as the quotation itself).
>>
>> Subsequent changes to the variable made by the quotation don't affect
>> the parent's local, but the quotation's own 'static' copy.
>> The effect is that you can pass data into a quotation at definition time
>> that is valid as long as the code without having to deal with eventual
>> 'quot-sys's on the stack.
>
> : foo { a } [: a ;] ;
> 5 foo constant bar1
> 7 foo constant bar2
> bar1 execute .
> bar2 execute .
> 3 foo constant bar3
> bar1 execute .
> bar2 execute .
>
> With only one (i.e., static) instance of A for BAR1, BAR2, and BAR3,
> this variant of outer locals will not be very useful.  And the little
> use it may have is covered by global VARIABLEs already.
>
> - anton
>

My first approach in <mpb11c$qj4$1@newsreader4.netcologne.de> and also 
its examples were flawed. Please see 
<mpcurt$2us$1@newsreader4.netcologne.de> for a reviewed proposal of 
mine, and <mpd3la$6fk$1@newsreader4.netcologne.de> for much better examples.

--
Regards,
Bernd

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

#40916

On Wednesday, July 29, 2015 at 5:18:52 PM UTC+2, Alex McDonald wrote:
> on 29/07/2015 15:44:03, Raimond Dragomir wrote:
> >>
> >> That now means we have to standardise an XT that "must execute within the
> >> scope of the caller and can't be saved for later". This is not how
> >> :NONAME and : work, and quotations are designed "to have the same
> >> privileges as words defined with : and :NONAME". Users and implementers
> >> are being advised here that supporting this type of XT is non-standard.
> >> But as is usual with Forth, they can do what they wish outside of the
> >> standard.
> >>
> > Why do you want to make it an umbiguous condition? Just say that the
> > outer locals are not visible and that's it. At least people will know
> > what the rule is. Compilers will throw an error that the "x" is an
> > unknown word and everybody is happy.
> 
> Someone may wish to implement, as Hugh and I have done, a system that
> allow reference to outer locals as long as the quotation isn't executed
> out of the execution scope of its parent. Why would you want to disallow
> that? The way this proposal is worded allows systems to offer more than
> the standard or the standard alone.
> 
> 
> > 
> >> >
> >> [[ and ]] have been proposed for POSTPONE source, and {: :} have been
> >> standardised as enclosing locals.
> > 
> > Since when? We don't have other standard than '94.
> 
> This one; http://www.forth200x.org/documents/forth14-5.pdf from
> http://www.forth200x.org.
> 
> {: :} are for locals. [[ and ]] are commonly used elsewhere, as are { }
> which bracket comments in Forth Inc systems.


I think that in the old discussion it was also proposed
to call the quotation recursively. I implement that with
the word MYSELF . Calling the outer word 'a' recursively
can be done in the ways shown in this thread.

-marcel

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

#40919

on 29/07/2015 19:16:36, mhx wrote:

> 
> 
> I think that in the old discussion it was also proposed
> to call the quotation recursively. I implement that with
> the word MYSELF . Calling the outer word 'a' recursively
> can be done in the ways shown in this thread.

For clarity

: foo 1 [: dup recurse ;] recurse ;

Here both RECURSEs would execute FOO?

: bar 1 [: dup myself ;] recurse ;

Here MYSELF executes the quotation?
 

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

#40921

On 29/07/2015 20:27, Alex McDonald wrote:
> on 29/07/2015 19:16:36, mhx wrote:
>
>>
>>
>> I think that in the old discussion it was also proposed
>> to call the quotation recursively. I implement that with
>> the word MYSELF . Calling the outer word 'a' recursively
>> can be done in the ways shown in this thread.
>
> For clarity
>
> : foo 1 [: dup recurse ;] recurse ;
>
> Here both RECURSEs would execute FOO?
>
> : bar 1 [: dup myself ;] recurse ;
>
> Here MYSELF executes the quotation?
>
>

I don't see the need for MYSELF. In my implementation RECURSE inside the 
quotation recurses the quotation. That seems most natural to me.

What would you do for nested quotations, invent a third recursing word?

-- 
Gerry

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

#40922

on 29/07/2015 21:57:10, Gerry Jackson wrote:
> On 29/07/2015 20:27, Alex McDonald wrote:
>> on 29/07/2015 19:16:36, mhx wrote:
>>
>>>
>>>
>>> I think that in the old discussion it was also proposed
>>> to call the quotation recursively. I implement that with
>>> the word MYSELF . Calling the outer word 'a' recursively
>>> can be done in the ways shown in this thread.
>>
>> For clarity
>>
>> : foo 1 [: dup recurse ;] recurse ;
>>
>> Here both RECURSEs would execute FOO?
>>
>> : bar 1 [: dup myself ;] recurse ;
>>
>> Here MYSELF executes the quotation?
>>
>>
> 
> I don't see the need for MYSELF. 

I see a need for you, don't worry. 

> In my implementation RECURSE inside
> the quotation recurses the quotation. That seems most natural to me.
> 
> What would you do for nested quotations, invent a third recursing
> word?
> 

RECURSE is used rarely, and I expect recursing quotations to be a
vanishing fraction of those. One word is enough.

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

#41011

On 29/07/2015 22:48, Alex McDonald wrote:
> on 29/07/2015 21:57:10, Gerry Jackson wrote:
>> On 29/07/2015 20:27, Alex McDonald wrote:
>>> on 29/07/2015 19:16:36, mhx wrote:
>>>
>>>>
>>>>
>>>> I think that in the old discussion it was also proposed
>>>> to call the quotation recursively. I implement that with
>>>> the word MYSELF . Calling the outer word 'a' recursively
>>>> can be done in the ways shown in this thread.
>>>
>>> For clarity
>>>
>>> : foo 1 [: dup recurse ;] recurse ;
>>>
>>> Here both RECURSEs would execute FOO?
>>>
>>> : bar 1 [: dup myself ;] recurse ;
>>>
>>> Here MYSELF executes the quotation?
>>>
>>>
>>
>> I don't see the need for MYSELF.
>
> I see a need for you, don't worry.
>
>> In my implementation RECURSE inside
>> the quotation recurses the quotation. That seems most natural to me.
>>
>> What would you do for nested quotations, invent a third recursing
>> word?
>>
>
> RECURSE is used rarely,

What's your evidence for this?

> and I expect recursing quotations to be a
> vanishing fraction of those.

A common pattern for recursion in Forth uses a recursing helper. The 
helper is more conveniently written as a quotation e.g. a trivial example:

: factorial 1 max [: dup 1- ?dup if recurse * then ;] execute . ;

> One word is enough.
>

Yes, RECURSE

-- 
Gerry

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

#41013

on 31/07/2015 12:34:50, Gerry Jackson wrote:
> On 29/07/2015 22:48, Alex McDonald wrote:

>>
>> RECURSE is used rarely,
> 
> What's your evidence for this?

http://www.complang.tuwien.ac.at/papers/gregg+01euroforth.ps.gz. Page 5
contains some Top 20 word counts.

An inspection of Win32Forth has about 15 uses; a few in the games like
Soduku and Pentominoes for solution solving, and in quicksort. There's an
appearance in the object classs routines where the code appears to
recursively search through vocabularies looking for a matching method;
quite why this one is recursion rather than a loop through a list isn't
clear to me.

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

#41017

"Alex McDonald" <blog@rivadpm.com> writes:
>on 31/07/2015 12:34:50, Gerry Jackson wrote:
>> On 29/07/2015 22:48, Alex McDonald wrote:
>
>>>
>>> RECURSE is used rarely,
>> 
>> What's your evidence for this?
>
>http://www.complang.tuwien.ac.at/papers/gregg+01euroforth.ps.gz. Page 5
>contains some Top 20 word counts.

That does not work as evidence for or against your claim.  These are
counts of primitives, and RECURSE compiles to the same primitive CALL
as any other call to a colon definition.  So you don't see there
wether the call is a recursion at all.

>An inspection of Win32Forth has about 15 uses;

Gforth:

[b8:~/gforth:8453] grep -i recursive *.fs */*.fs|wc -l
14
[b8:~/gforth:8454] grep -i recurse *.fs */*.fs|wc -l
79

This includes occurences in comments and stuff that is not recursion,
but just a reference to the last definition, e.g.:

Defer android-surface-redraw ' ]gref is recurse

instead of

Defer android-surface-redraw ' ]gref is android-surface-redraw

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

#41022

On Friday, July 31, 2015 at 2:00:56 PM UTC+2, Alex McDonald wrote:
> on 31/07/2015 12:34:50, Gerry Jackson wrote:
> > On 29/07/2015 22:48, Alex McDonald wrote:
> 
> >>
> >> RECURSE is used rarely,
> > 
> > What's your evidence for this?
> 
> http://www.complang.tuwien.ac.at/papers/gregg+01euroforth.ps.gz. Page 5
> contains some Top 20 word counts.
> 
> An inspection of Win32Forth has about 15 uses; a few in the games like
> Soduku and Pentominoes for solution solving, and in quicksort. There's an
> appearance in the object classs routines where the code appears to
> recursively search through vocabularies looking for a matching method;
> quite why this one is recursion rather than a loop through a list isn't
> clear to me.

Searching for: recurse in /dfwforth
Found 445 occurrence(s) in 147 file(s)

Searching for: myself in /dfwforth
Found 149 occurrence(s) in 16 file(s)

Searching for: recurse in /idfwforth64
Found 67 occurrence(s) in 30 file(s)

Searching for: recurse in /idfwforth
Found 196 occurrence(s) in 69 file(s)

Searching for: myself in /idfwforth
Found 9 occurrence(s) in 5 file(s)

-marcel

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

#40942

On Wednesday, July 29, 2015 at 9:27:46 PM UTC+2, Alex McDonald wrote:
> on 29/07/2015 19:16:36, mhx wrote:
> 
> > 
> > 
> > I think that in the old discussion it was also proposed
> > to call the quotation recursively. I implement that with
> > the word MYSELF . Calling the outer word 'a' recursively
> > can be done in the ways shown in this thread.
> 
> For clarity
> 
> : foo 1 [: dup recurse ;] recurse ;
> 
> Here both RECURSEs would execute FOO?
> 
> : bar 1 [: dup myself ;] recurse ;
> 
> Here MYSELF executes the quotation?

I am sorry, I see the RfD already discusses RECURSE up front.
MYSELF was needed at the time of the original discussion 
because I defined [: and ;] in high-level using :noname (which 
at that time didn't support RECURSE). 

As the current iForth's RECURSE is nestable and allows :noname 
I redraw the comment.

-marcel

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

#40950

on 30/07/2015 05:42:51,  wrote:
> On Wednesday, July 29, 2015 at 9:27:46 PM UTC+2, Alex McDonald wrote:
>> on 29/07/2015 19:16:36, mhx wrote:
>>
>> >
>> >
>> > I think that in the old discussion it was also proposed
>> > to call the quotation recursively. I implement that with
>> > the word MYSELF . Calling the outer word 'a' recursively
>> > can be done in the ways shown in this thread.
>>
>> For clarity
>>
>> : foo 1 [: dup recurse ;] recurse ;
>>
>> Here both RECURSEs would execute FOO?
>>
>> : bar 1 [: dup myself ;] recurse ;
>>
>> Here MYSELF executes the quotation?
> 
> I am sorry, I see the RfD already discusses RECURSE up front.
> MYSELF was needed at the time of the original discussion
> because I defined [: and ;] in high-level using :noname (which
> at that time didn't support RECURSE).
> 
> As the current iForth's RECURSE is nestable and allows :noname
> I redraw the comment.
> 
> -marcel
> 

OK, thanks for the clarification.

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

#40929

On Wednesday, July 29, 2015 at 8:18:52 AM UTC-7, Alex McDonald wrote:
> on 29/07/2015 15:44:03, Raimond Dragomir wrote:
> >>
> >> That now means we have to standardise an XT that "must execute within the
> >> scope of the caller and can't be saved for later". This is not how
> >> :NONAME and : work, and quotations are designed "to have the same
> >> privileges as words defined with : and :NONAME". Users and implementers
> >> are being advised here that supporting this type of XT is non-standard.
> >> But as is usual with Forth, they can do what they wish outside of the
> >> standard.
> >>
> > Why do you want to make it an umbiguous condition? Just say that the
> > outer locals are not visible and that's it. At least people will know
> > what the rule is. Compilers will throw an error that the "x" is an
> > unknown word and everybody is happy.
> 
> Someone may wish to implement, as Hugh and I have done, a system that
> allow reference to outer locals as long as the quotation isn't executed
> out of the execution scope of its parent. Why would you want to disallow
> that? The way this proposal is worded allows systems to offer more than
> the standard or the standard alone.

Your RfD said:
On Tuesday, July 28, 2015 at 1:22:17 PM UTC-7, Alex McDonald wrote: 
> Locals: A quotation may not be able to access the locals of the outer 
> word because it has no knowledge of when it might be executed and 
> hence whether outer locals are still alive. It does permit defining and 
> accessing its own locals. 

But now you say that you do allow the quotation to have access to the parent function's local variables. This is a gross contradiction.

Previously we had this exchange:

On Tuesday, July 14, 2015 at 10:48:42 AM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, July 14, 2015 at 9:50:35 AM UTC-7, Alex McDonald wrote:
> > on 14/07/2015 17:32:47,  wrote:
> > > Notice
> > > how the quotation accesses the CNT local variable of the COUNT-FEMALES
> > > function when it is executed inside of the EACH function ?
> > 
> > All you've done
> > here is explain how any XT -- quotation, :NONAME, or tick of a named word
> > -- can be used in one specific kind of higher order function.
> 
> Alex McDonald is a liar --- he is purposely ignoring the fact that my quotations have access to the parent functions local variables (the CNT local in this example) when they are executed inside of the higher-order function.
> 
> This is the same lie that he was telling in this thread:
> https://groups.google.com/forum/#!topic/comp.lang.forth/C_NDoMSUAx0%5B76-100%5D
> 
> On Sunday, July 5, 2015 at 7:57:51 PM UTC-7, hughag...@gmail.com wrote:
> > On Sunday, July 5, 2015 at 2:36:05 AM UTC-7, Alex McDonald wrote:
> > > Then, as Hugh complains about Bernd's "faked quotations", his FMITE is no
> > > more than :NONAME syntactic sugar. Perhaps worse, as from what I read
> > > there the language does not permit use of the quotation outside of its
> > > enclosing word.
> > 
> > Alex McDonald is lying --- as usual.
> 
> Alex just tells the same lie over and over again, in the hope that somebody will eventually believe it. If he gets caught lying (he always does), he just waits a few days and then tells the same lie again.
> 
> The reason why he does this is that he knows that so long as he is supporting Forth-200x, the Forth-200x committee will support him.

Now you say that "Hugh and I" have developed quotations that can access the local variables in the parent function. You have never contributed anything --- you are trying to take credit for the FMITE now --- you are a chronic liar!

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

#40949

on 30/07/2015 01:21:47, hugha  wrote:

> 
> Your RfD said:
> On Tuesday, July 28, 2015 at 1:22:17 PM UTC-7, Alex McDonald wrote:
>> Locals: A quotation may not be able to access the locals of the outer
>> word because it has no knowledge of when it might be executed and
>> hence whether outer locals are still alive. It does permit defining and
>> accessing its own locals.
> 
> But now you say that you do allow the quotation to have access to the
> parent function's local variables. This is a gross contradiction.

My implementation meets the requirements of the proposed RfD.
*Additionally*, it allows referring to the parent's locals. This is not
contradictory.

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

#40959

Le jeudi 30 juillet 2015 10:56:22 UTC+2, Alex McDonald a écrit :

> My implementation meets the requirements of the proposed RfD.
> *Additionally*, it allows referring to the parent's locals. This is not
> contradictory.

Hello,

If Hugh, Raimond and you have implemented access to parent local why not propose
this into the RFD ?

btw, what is called "ambiguous" into the RFD is ... ambiguous to me...

RFD only talks about quotations executed when locals are no more alive to
conclude that this is ambiguous to refer to parent locals.

Is this ambiguity only apply to this case or, if this RFD becomes standard,
will a programm with a quotation that refer to parent locals while remaining
into the parent scope will be standard or not ? Will it be a portable program ?

If yes, it should be explicitly written that this case is allowed and MUST be
supported.

If no, what you mean is that, no matter why, a quotation SHOULD NOT refer
to parent locals to be standard and portable, not that this is an ambiguous
condition. 

Imo, this should be stated into the RFD without... ambiguity... no ?

Franck.

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

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

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

csiph-web