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

#40577

franck.bensusan@gmail.com writes:
>> 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 :=20
>
>1) 2 parameters are needed for the quotation=20
>- 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...

I cannot follow you here.  Please present code (and something close to
Forth, so I can understand it).

>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=20
>not disturb the data stack.

I cannot follow you here, either.

>3) The high order function needs 2 quotations (or words)
>
>Example :=20
>Sorry for oforth code (should be readable, quotations are #[ ... ])
>
>: test(c, a, b) { c mapIf(#[ a <=3D ], #[ 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 :=20
>
>: test(c, a, b) { b a #[ 3 pick + ] #[ over <=3D ] c mapIf nip nip }

Yes, I think that's what Bernd Paysan has in mind.

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

Yes, you probably need some PICKing or maybe even STICKing for this
kind of coding.  I guess this will lead to purists condemning
programming with high-order words.

>It took me 1 minute to have it work whereas the former was=20
>done in 1 second without error and without bothering about the stack.

50 characters in one second!  You are a fast typist, and also
extremely fast in programming.

>4) The quotation needs to accumulate a value :
>
>Example : a word that calculate the sum of a serie
>for instance : sum of 1/n2=20
>
>: 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 :
>=20
>: 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=20
>sumSerie is written. If a parameter is needed, it must be=20
>into the quotation, not on the data stack.

It looks like you managed to make it follow his convention; the code
is too far from Forth for me to fully understand it, so I don't see
where your problem is.

Sure, if a word does not follow his convention, you cannot use the
stack for additional stuff.  The question is: Is it possible to follow
the convention?  If it is, is it too cumbersome?

>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 :=20
>: test(a) { sumSerie(#[ a + ], 10) }
>10 test .
>155

I'll try to implement SUM-SERIES in Forth based on an high-order
enumeration word.

: for ( ... u xt -- ... )
    \ xt ( ... u1 -- ... )
    { xt } 1+ 1 ?do i xt execute loop ;
: sum-series ( ... u xt -- ... r )
  \ xt ( ... u1 -- ... r )
  0e swap [: swap dup >r execute r> f+ ;] for ;
: test1 1000 [: 1e dup * s>f f/ ;] sum-series ;
test1 cr f.
: test ( u -- )
  10 [: over + s>f ;] sum-series ;
10 test cr f.

Tested.  Works.  It did take me quite a bit of time to get this right,
however.  If we want to write a lot of higher-order words, and use
them a lot, access to outer locals is a good idea.

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

Yes.

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

#40587

Le lundi 13 juillet 2015 19:30:28 UTC+2, Anton Ertl a écrit :
> 
> I'll try to implement SUM-SERIES in Forth based on an high-order
> enumeration word.
> 
> : for ( ... u xt -- ... )
>     \ xt ( ... u1 -- ... )
>     { xt } 1+ 1 ?do i xt execute loop ;
> : sum-series ( ... u xt -- ... r )
>   \ xt ( ... u1 -- ... r )
>   0e swap [: swap dup >r execute r> f+ ;] for ;
> : test1 1000 [: 1e dup * s>f f/ ;] sum-series ;
> test1 cr f.
> : test ( u -- )
>   10 [: over + s>f ;] sum-series ;
> 10 test cr f.
> 
> Tested.  Works. It did take me quite a bit of time to get this right,
> however.  

Yes, it works here, but the reason it works is that floats have a separate 
stack and they don't polluate the data stack when access to parameters.
(it is not the case for my version).

It is more challenging to follow this convention if the float stack
is not used to store the intermediary result (integers for instance) : 

: for ( ... u xt -- ... )
    \ xt ( ... u1 -- ... )
    { xt } 1+ 1 ?do i xt execute loop ;

: sum-series ( ... u xt -- ... r )
  \ xt ( ... u1 -- ... r )
  0 swap [: swap dup >r execute r> + ;] for ;

: test ( u -- )
  10 [: over + ;] sum-series ;

10 test cr . 

This code does not work and does not follow this convention, of course 
(I just replaced float by integers in your code to not use the float stack).

But having this code work and follow the convention is another story ... :)


> If we want to write a lot of higher-order words, and use
> them a lot, access to outer locals is a good idea.
> 

Yes, I think this is the best option.

Franck

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

#40601

franck.bensusan@gmail.com writes:
>Le lundi 13 juillet 2015 19:30:28 UTC+2, Anton Ertl a =E9crit=A0:
>>=20
>> I'll try to implement SUM-SERIES in Forth based on an high-order
>> enumeration word.
>>=20
>> : for ( ... u xt -- ... )
>>     \ xt ( ... u1 -- ... )
>>     { xt } 1+ 1 ?do i xt execute loop ;
>> : sum-series ( ... u xt -- ... r )
>>   \ xt ( ... u1 -- ... r )
>>   0e swap [: swap dup >r execute r> f+ ;] for ;
>> : test1 1000 [: 1e dup * s>f f/ ;] sum-series ;
>> test1 cr f.
>> : test ( u -- )
>>   10 [: over + s>f ;] sum-series ;
>> 10 test cr f.
>>=20
>> Tested.  Works. It did take me quite a bit of time to get this right,
>> however. =20
>
>Yes, it works here, but the reason it works is that floats have a separate=
>=20
>stack and they don't polluate the data stack when access to parameters.
>(it is not the case for my version).

Well, you gave an example that, when implemented in Forth, requires
the FP stack, so I implemented that.

So now you want a version of SUM-SERIES that produces an integer
result?  Let's see:

: for ( ... u xt -- ... )
    \ xt ( ... u1 -- ... )
    { xt } 1+ 1 ?do i xt execute loop ;
: nsum-series ( ... u xt -- ... n )
    \ xt ( ... u1 -- ... n1 )
    0 swap rot
    [: ( ... u0 xt u1 -- ... u2 xt )
        over >r rot >r swap execute r> + r>
    ;] for drop ;
: test ( u1 -- u2 )
    10 [: over + ;] nsum-series nip ;
10 test cr . cr

An alternative implementation of NSUM-SERIES with locals (without
access to outer locals):

: nsum-series ( ... u xt -- ... n )
    \ xt ( ... u1 -- ... n1 )
    {: u xt :} 0 xt u
    [: {: u0 xt1 u1 -- u2 xt1 :} u1 xt1 execute u0 + xt1 ;] for drop ;

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

#40607

Le mardi 14 juillet 2015 09:17:56 UTC+2, Anton Ertl a écrit :
> 
> Well, you gave an example that, when implemented in Forth, requires
> the FP stack, so I implemented that.
> 

Yes, I know. I didn't realized that it would use Forth float stack 
and simplify the code.


> So now you want a version of SUM-SERIES that produces an integer
> result?  Let's see:
> 
> : for ( ... u xt -- ... )
>     \ xt ( ... u1 -- ... )
>     { xt } 1+ 1 ?do i xt execute loop ;
> : nsum-series ( ... u xt -- ... n )
>     \ xt ( ... u1 -- ... n1 )
>     0 swap rot
>     [: ( ... u0 xt u1 -- ... u2 xt )
>         over >r rot >r swap execute r> + r>
>     ;] for drop ;
> : test ( u1 -- u2 )
>     10 [: over + ;] nsum-series nip ;
> 10 test cr . cr
> 

I don't "want". It is just to show that, in this case, the quotation is even 
more complicated. 

But, strangly, still readable when you have already see this kind of
coding style... (but someone that don't know what's happens here
is probably lost).

> An alternative implementation of NSUM-SERIES with locals (without
> access to outer locals):
> 
> : nsum-series ( ... u xt -- ... n )
>     \ xt ( ... u1 -- ... n1 )
>     {: u xt :} 0 xt u
>     [: {: u0 xt1 u1 -- u2 xt1 :} u1 xt1 execute u0 + xt1 ;] for drop ;
> 

Interesting alternative.

Franck.

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

#40517

Am 10.07.2015 um 17:29 schrieb Alex McDonald:
 > on 10/07/2015 15:13:06, 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.
 >

"Static" and "dynamic" language references visibility/accessibility 
(scope) of symbols and lifetime (extent) of [local] variables.

Static (better: lexical) scoping means, you can derive the visibility of 
a symbol by examining the hierarchy in the source. The symbol is 
accessible within the block (function) it is defined in, and all the 
block's lexical children (functions in functions, local classes, 
quotations), but not its siblings or parent. This is standard in all 
newer languages that base on ALGOL. It can easily be implemented using 
stack frames.

With dynamic scoping, not the source code, but the runtime call chain 
determines visibility of symbols independently of their lexical 
relation. A called function may access variables defined in the calling 
function, even if they are defined in different locations.
Symbol accesses in such languages normally involve a symbol lookup at 
runtime, if the name can not be statically resolved at compile time -- 
which is the case for all non-locally defined symbols.

The extent describes when during the program's execution a variable's 
binding is retained. ALGOL-like languages have commonly *static extent*, 
meaning that their variables contents are lost when they go out of scope 
(the execution reaches their defining block's end). There are sometimes 
alternatives, e.g. C's "static" variables (with static scope and 
*infinite extent*), that have to be initialized when being defined and 
retain their bindings until termination of the program. Anytime the 
variable comes into scope (by execution of its containing block), you 
can access it (scope), and get the last assigned value (extent). The 
initialization is performed only once, at the first invocation.
Dynamic extent is still beyond this concept. With dynamic extent, 
variables exist in "activation records" or "environments", which, once 
created, persist as long as they could possibly be accessed, thus 
requiring garbage collection if one wants to reclaim this memory. A 
function with a living activation record becomes a closure, effectively 
holding a state between calls to that function. Lips's lambda functions 
and JavaScript's constructor functions are such closures.

I hope that makes the concepts and terms clearer.
Regards,
Bernd

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

#40519

Am 11.07.2015 um 11:03 schrieb Bernd Linsel:
 >
 > Am 10.07.2015 um 17:29 schrieb Alex McDonald:
 >  > on 10/07/2015 15:13:06, 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.
 >  >
 >
 > [...]
 > With dynamic extent,
 > variables exist in "activation records" or "environments", which, once
 > created, persist as long as they could possibly be accessed, thus
 > requiring garbage collection if one wants to reclaim this memory.

Clarification:

GC is of course not *required*, the function and its environment may 
e.g. also reside within an instance of a class containing the state, and 
object's lifetime is controlled by the usual C++ means.

Regards,
Bernd

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

#40555

On Saturday, July 11, 2015 at 2:10:49 AM UTC-7, Bernd Linsel wrote:
> Am 11.07.2015 um 11:03 schrieb Bernd Linsel:
>  >
>  > Am 10.07.2015 um 17:29 schrieb Alex McDonald:
>  >  > on 10/07/2015 15:13:06, 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.
>  >  >
>  >
>  > [...]
>  > With dynamic extent,
>  > variables exist in "activation records" or "environments", which, once
>  > created, persist as long as they could possibly be accessed, thus
>  > requiring garbage collection if one wants to reclaim this memory.
> 
> Clarification:
> 
> GC is of course not *required*, the function and its environment may 
> e.g. also reside within an instance of a class containing the state, and 
> object's lifetime is controlled by the usual C++ means.
> 
> Regards,
> Bernd

GC isn't required --- but GC is the hallmark of dynamic-OOP languages, so Raimond was pretty much right.

I think that GC is a no-go in a real-time micro-controller. The Lisp crowd disagrees:
https://groups.google.com/forum/#!topic/comp.lang.lisp/-nWfXAs_4ug

On Thursday, July 2, 2015 at 1:06:22 AM UTC-7, informatimago wrote:
> hughaguilar96@gmail.com writes:
> 
> > On Tuesday, June 30, 2015 at 11:59:44 PM UTC-7, informatimago wrote:
> >> hughaguilar96@gmail.com writes:
> >> > AFAIK, I'm the only person attempting to bring lambda functions to
> >> > micro-controllers. Certainly, GC is a no-go in a real-time system no
> >> > matter how fast the processor is, because GC causes stuttering and
> >> > hence it is not possible to ensure that code executes in the time
> >> > allotted to it.
> >> 
> >> Nonetheless, you need to learn more. Much more!
> >
> > My background is that I wrote MFX, the Forth cross-compiler, assembler and simulator for this processor:
> > http://www.testra.com/Forth/RACE.htm
> > Because of this experience, I know something about what can be done in
> > a custom processor (the MiniForth was built on a Lattice isp1048 PLD).
> >  
> >> There are a lot of real-time GC algorithms (and even parallel and
> >> multi-threaded GC algorithms), that are able to collect garbage with no
> >> pause ever.
> >
> > Multi-threading doesn't prevent pauses --- multi-threading is all
> > about pausing (that is why they have a PAUSE command for switching
> > tasks). As for parallel-processing (presumably with dual-port memory),
> > that is way out of my league --- I'm just designing a
> > micro-controller.
> 
> Of course. That's why, if you're smart, you will ignore the
> parenthetical mention of multi-threaded GC algorithms, and use instead
> the  real-time, pauseless GC algorithms!  
> 
> 
> > All in all, I think you are beating me up for not bringing
> > desktop-computer programming to the micro-controller that is
> > unrealistic
> 
> No. I'm beating you up for not using google for:
>    real-time garbage collector
> or pauseless garbage collector
> or hardware garbage collector
> and coming here telling us that "GC is a no-go in a real-time system".
> 
> -- 
> __Pascal Bourguignon__                 http://www.informatimago.com/
> "The factory of the future will have only two employees, a man and a
> dog. The man will be there to feed the dog. The dog will be there to
> keep the man from touching the equipment." -- Carl Bass CEO Autodesk

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

#40527

Bernd Linsel <bl1@gmx.com> writes:
>
>Am 10.07.2015 um 17:29 schrieb Alex McDonald:
>"Static" and "dynamic" language references visibility/accessibility 
>(scope) of symbols and lifetime (extent) of [local] variables.

Well, static scoping has mostly won, so few people write about scoping
these days, and use the term static and dynamic language in that
sense.  I see the terms more often referring to type-checking.
Sometimes it also refers to other aspects of the language, e.g.,
Andrew Haley once wrote that Java is a dynamic language; obviously he
meant neither scoping nor type-checking.

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

#40541

On Saturday, July 11, 2015 at 10:26:56 AM UTC-5, Anton Ertl wrote:
> Bernd Linsel <bl1@gmx.com> writes:
> >
> >Am 10.07.2015 um 17:29 schrieb Alex McDonald:
> >"Static" and "dynamic" language references visibility/accessibility 
> >(scope) of symbols and lifetime (extent) of [local] variables.
> 
> Well, static scoping has mostly won, so few people write about scoping
> these days, and use the term static and dynamic language in that
> sense.

Yeah, people do not say that Perl is a static language, even though
lexical scoping has been dominant in it since my() was introduced.
I think people also do not much like language classifications that
aren't exclusive: Perl still supports dynamic scoping with local().

Common Lisp is the same way: lexical by default, but you can also
have dynamic scoping where appropriate, and in the Common Lisp
community if you don't put a scarlet 'D' on every piece of clothing
for a dynamically scoped variable the community will arouse itself
in a puritan fury against you.  Seriously.  The best programming
book ever about macros, Let Over Lambda, is a bad book that
shouldn't be read because the author unimportantly doesn't believe
that it's necessary to always name dynamic variables with
*asterisks*.

The support these languages have for dynamic variables is basically 

  : call ( return -- )  >r ;
  : dynamic-! ( value address -- )
    r> -rot dup @ over 2>r !
    ['] call catch 2r> ! throw ;

Allowing for:

  : hex. ( n -- )
    16 base dynamic-!  . ;

In Common Lisp variables know that they are dynamic, and BASE is a
variable that would typically be such, so that could be written as

  variable hex-usage
  : hex. ( n -- )
    16 base !  1 hex-usage +!
    . ;

and people would just know that the value of BASE is reset after
HEX. exits, but that HEX-USAGE retains it updated value.  Or with
the scarlet 'D':

  variable hex-usage
  : hex. ( n -- )
    16 *base* !  1 hex-usage +!
    . ;

> I see the terms more often referring to type-checking.
> Sometimes it also refers to other aspects of the language, e.g.,
> Andrew Haley once wrote that Java is a dynamic language; obviously he
> meant neither scoping nor type-checking.
> 
> - 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]

#40550

Julian Fondren <julian.fondren@gmail.com> writes:
>The support these languages have for dynamic variables is basically 
>
>  : call ( return -- )  >r ;
>  : dynamic-! ( value address -- )
>    r> -rot dup @ over 2>r !
>    ['] call catch 2r> ! throw ;
>
>Allowing for:
>
>  : hex. ( n -- )
>    16 base dynamic-!  . ;

Thank you for this example of a word that uses return-address
manipulation to treat a part of a colon definition in a quotation-like
way (which I mentioned in another sub-thread).

In this case the two sub-definitions are

16 base dynamic-!

and

.

We can define DYNAMIC-! to take an xt, and then this example would
look as follows:

: dynamic-! ( value address xt -- )
  -rot dup @ over 2>r ! catch 2r> ! throw ;
: hex. ( n -- )
  16 base ['] . dynamic-! ;

And for creating the xt that is passed to DYNAMIC-!, quotations can be
useful.

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

#40491

on 10/07/2015 08:35:39, Michael Barry wrote:
> On Tuesday, July 7, 2015 at 12:30:40 AM UTC-7, Alex McDonald wrote:
>> ...
>> Ummm... what didn't I understand about the original words "It is
>> illegal to execute the xt of a quotation after the parent function
>> has gone out of scope?" This looks like a slam dunk to me.
>>
> 
> I read Hugh's document carefully at least once, and it's a bit too
> advanced for me to understand it completely, but my impression is
> that you are correct.  If an orphaned quotation is called, it
> would happily execute, but would likely corrupt the stack.  Is
> this some kind of catastrophic failure in the design, or just an
> implementation decision that needs to be carefully followed?

No, it's just that Hugh thinks he's fixed a problem. He tells anyone who
disagrees that they're idiots and they don't understand closures and
quotations, and documents the solution in FMITE. Only to have me point
out that that he hasn't actually fixed the problem, and his solution is
more limited than it need be and is stated in ambiguous language,
something he rails against in the ANS spec. 


> 
>> ...
>> I couldn't get your code to work. I imagine most other people didn't
>> try.
>>
> 
> I was waiting for him to share his simulator with me before I tried
> his code.  Did you use his document to whip up your own simulator,
> or are you executing it by hand (or in your head)?  I know that
> you're a pretty sharp cookie, but it puzzles me that you would
> bother to expend the effort.  I know that Hugh isn't interested in
> your opinion, but I am.  Could you share a few thoughts about what
> you feel may be the merits and/or faults of his design?  I, for
> one, thought that it was kind of neat, and I don't feel eccentric
> or ignorant enough to be the only one here who thought so.

The code Hugh was refering to was his "disambiguifiers". It's was an
attempt to get ANS Forth work the way Hugh wants it to.

I've done none of the things you mention apart from give his FMITE
document a brief read. I always have difficulty reading Hugh's stuff as
considerable chunks of it normally end up defaming named individuals and
accusing them of grandiose plans of world domination, and the same is
true in FMITE. I also find most of his technical stuff has similar
problems; it is discursive and not very illuminating windbaggery. 

> 
> Mike B.
> 
> 

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

#40514

On Tuesday, July 7, 2015 at 12:30:40 AM UTC-7, Alex McDonald wrote:
> on 07/07/2015 03:59:28,  wrote:
> > On Monday, July 6, 2015 at 12:09:53 AM UTC-7, Alex McDonald wrote:
> >> on 06/07/2015 03:57:53,  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 a liar. He said: "Hugh complains about Bernd's 'faked quotations', his FMITE is no more than :NONAME syntactic sugar."

He is totally lying --- my quotations have access to the parent function's local variables --- this wasn't an obscure point that he somehow missed; this is the point of the FMITE, so this was described repeatedly throughout the document.
 
He said: "Perhaps worse, as from what I read there the language does not permit use of the quotation outside of its enclosing word."

He is totally lying --- the quotation is passed into higher-order functions and they execute it --- once agin

> Ummm... what didn't I understand about the original words "It is illegal
> to execute the xt of a quotation after the parent function has gone out
> of scope?" This looks like a slam dunk to me.

Alex McDonald is not trying to understand --- he just wants to support ANS-Forth and Forth-200x by lying about competing ideas --- he wants to make a "slam dunk," but this is not a positive contribution from any perspective.

> Point out my lies, or expect my lawyers (Butt, Hurt & Cox LLP) to be in
> contact by the end of the week.

Alex McDonald is fishing for praise from Elizabeth Rather so that this will be a total "slam dunk" for him. So, we will give him what he wants (just substitute "Alex" for "John" in the following):

On Sunday, November 29, 2009 at 7:07:39 PM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> > I ignored your lengthy post because of your vulgar mindset. Here are
> > some examples:
> > ...
> > Your use of the terms "sucks" and "ass" indicate that you are member
> > of a community of people that don't belong on comp.lang.forth. You
> > should already be well aware of my opinion of this community of
> > people, and you should not have used your community's terminology in a
> > post directed at a decent person such as myself. I suggest that you go
> > back to your own community, where such language is appreciated, and
> > stop posting vulgar messages on comp.lang.forth.
> 
> Ok, Hugh, that's the last straw.  You're in my "kill file" now.  I have 
> no interest in any further postings from you on any subject.
> 
> Not because I have any great personal affinity for John -- I've never 
> met him, and know him only through his posts here, which are unfailingly 
> interesting, perceptive, and technically sound (even when we disagree). 
>   But I am *personally* offended by your homophobic bias and use of 
> personal insults.  I do not choose to converse with people of your 
> intolerant mindset.  John has made far more technical contributions to 
> comp.lang.forth than you have.
> 
> Bye.
> 
> Elizabeth

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

#40305

Le dimanche 5 juillet 2015 11:04:18 UTC+2, Raimond Dragomir a écrit :
> 
> if myloc is a "normal" local variable (on a stack, NOT on a heap) this 
> won't work in any forth. At the time of the execute, the myloc variable is 
> out of scope.
> 
> In what forth is it working?
> 

Hello,

This is working in Oforth. 

: foo(x) { #[ x 1 + ] }
10 foo perform .
11 ok

: foo(x) { #[ x + ] }
10 12 foo perform .
22 ok

10 20 foo tuck perform swap perform .
50 ok

Franck

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

#40306

duminică, 5 iulie 2015, 13:47:54 UTC+3, franck....@gmail.com a scris:
> Le dimanche 5 juillet 2015 11:04:18 UTC+2, Raimond Dragomir a écrit :
> > 
> > if myloc is a "normal" local variable (on a stack, NOT on a heap) this 
> > won't work in any forth. At the time of the execute, the myloc variable is 
> > out of scope.
> > 
> > In what forth is it working?
> > 
> 
> Hello,
> 
> This is working in Oforth. 
> 
> : foo(x) { #[ x 1 + ] }
> 10 foo perform .
> 11 ok
> 
> : foo(x) { #[ x + ] }
> 10 12 foo perform .
> 22 ok
> 
> 10 20 foo tuck perform swap perform .
> 50 ok
> 
> Franck

Oforth is a dynamic language :)

In a static system the locals are on a stack and loose their scope when the
parent exits. For these systems, such test cases should be all completed 
in the parent:

def foo  [{ x } x @ 1+ ] execute ;
foo reDef
 ok
10 foo .
11  ok
def bar  [{ x } x @ [{ y } y @ 1+ ] execute 1+ x @ + ] execute ;
bar reDef
 ok
10 bar .
22  ok
def foobar { | x y }  [ x ! x @ [ y ! y @ 1+ ] execute 1+ x @ + ] execute ;
foobar reDef
 ok
10 foobar .
22  ok

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

#40307

duminică, 5 iulie 2015, 14:15:40 UTC+3, Raimond Dragomir a scris:
> duminică, 5 iulie 2015, 13:47:54 UTC+3, franck....@gmail.com a scris:
> > Le dimanche 5 juillet 2015 11:04:18 UTC+2, Raimond Dragomir a écrit :
> > > 
> > > if myloc is a "normal" local variable (on a stack, NOT on a heap) this 
> > > won't work in any forth. At the time of the execute, the myloc variable is 
> > > out of scope.
> > > 
> > > In what forth is it working?
> > > 
> > 
> > Hello,
> > 
> > This is working in Oforth. 
> > 
> > : foo(x) { #[ x 1 + ] }
> > 10 foo perform .
> > 11 ok
> > 
> > : foo(x) { #[ x + ] }
> > 10 12 foo perform .
> > 22 ok
> > 
> > 10 20 foo tuck perform swap perform .
> > 50 ok
> > 
> > Franck
> 
> Oforth is a dynamic language :)
> 
> In a static system the locals are on a stack and loose their scope when the
> parent exits. For these systems, such test cases should be all completed 
> in the parent:
> 
> def foo  [{ x } x @ 1+ ] execute ;
> foo reDef
>  ok
> 10 foo .
> 11  ok
> def bar  [{ x } x @ [{ y } y @ 1+ ] execute 1+ x @ + ] execute ;
> bar reDef
>  ok
> 10 bar .
> 22  ok
> def foobar { | x y }  [ x ! x @ [ y ! y @ 1+ ] execute 1+ x @ + ] execute ;
> foobar reDef
>  ok
> 10 foobar .
> 22  ok

On the other hand, if the quotations have their own locals, they work
outside the parent.

def xt+  [{ x y } x @ y @ + ] ;
 ok
1 2 xt+ execute .
3  ok
def xt+2 { a b } a @ [{ x y } x @ y @ + ] swap b @ + swap execute ;
 ok
100 1 2 xt+2 .
103  ok

Only that a quotation with own locals cannot "see" parent's locals, even
if they are different names.

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

#40309

> def xt+2 { a b } a @ [{ x y } x @ y @ + ] swap b @ + swap execute ;
>  ok
> 100 1 2 xt+2 .
> 103  ok
> 
> Only that a quotation with own locals cannot "see" parent's locals, even
> if they are different names.

This is the example with the quotation having locals with the same name
with parent's:

def xt+2 { a b } a @ [{ a b } a @ b @ + ] swap b @ + swap execute ;
xt+2 reDef
 ok
100 1 2 xt+2 .
103  ok

And here we can see that the 'a' local in quotation is unknown. The
quotation local frame { x y } hides parent's frame { a b } regardless the
locals name.

def xt+2 { a b } a @ [{ x y } x @ y @ + a @ + ] swap b @ + swap execute ;
xt+2 reDef
stdin(1): Error: a : unknown word
 ok

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

#40313

Le dimanche 5 juillet 2015 13:15:40 UTC+2, Raimond Dragomir a écrit :
> In a static system the locals are on a stack and loose their scope when the
> parent exits. For these systems, such test cases should be all completed 
> in the parent:
> 

Same in Oforth : locals are on stack too and loose their scope when the parent
exit.

What is dynamic is the quotation itself. When created (and if it uses locals),
it is created on the heap and store values of the locals used.
When executed, it creates its own local frame (on the stack) with values 
initialized with those stored when created.

[toc] | [prev] | [standalone]

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

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

csiph-web