Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37262 > unrolled thread
| Started by | grobibi <tristanhennequin@free.fr> |
|---|---|
| First post | 2015-03-15 00:43 +0100 |
| Last post | 2015-07-05 08:44 -0700 |
| Articles | 20 on this page of 127 — 24 participants |
Back to article view | Back to comp.lang.forth
local variable grobibi <tristanhennequin@free.fr> - 2015-03-15 00:43 +0100
Re: local variable "Elizabeth D. Rather" <erather@forth.com> - 2015-03-14 15:01 -1000
Re: local variable grobibi <tristanhennequin@free.fr> - 2015-03-15 02:50 +0100
Re: local variable Gerard Sontag <gerardsontag@gmail.com> - 2015-07-11 09:49 -0700
Re: local variable Coos Haak <chforth@hccnet.nl> - 2015-07-11 22:50 +0200
Re: local variable Gerard Sontag <gerardsontag@gmail.com> - 2015-07-12 01:03 -0700
Re: local variable Coos Haak <chforth@hccnet.nl> - 2015-07-12 17:18 +0200
Re: local variable albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-15 03:02 +0000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-15 02:53 +0100
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2015-03-17 22:29 +0000
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2016-02-08 14:45 +0000
Re: local variable hughaguilar96@gmail.com - 2015-03-14 20:45 -0700
Re: local variable stephen@mpeforth.com (Stephen Pelc) - 2015-03-15 10:53 +0000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-15 22:54 +0100
Re: local variable hughaguilar96@gmail.com - 2015-03-15 19:45 -0700
Re: local variable hughaguilar96@gmail.com - 2015-03-15 20:15 -0700
Re: local variable grobibi <tristanhennequin@free.fr> - 2015-03-16 08:42 +0100
Re: local variable stephen@mpeforth.com (Stephen Pelc) - 2015-03-16 07:51 +0000
Re: local variable hughaguilar96@gmail.com - 2015-03-16 09:59 -0700
Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-03-16 20:31 +0000
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2015-03-18 08:59 +0000
Re: local variable "HAA" <someone@microsoft.com> - 2015-03-17 13:47 +1100
Re: local variable stephen@mpeforth.com (Stephen Pelc) - 2015-03-17 10:59 +0000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-17 18:55 +0100
Re: local variable stephen@mpeforth.com (Stephen Pelc) - 2015-03-17 18:43 +0000
Re: local variable "HAA" <someone@microsoft.com> - 2015-03-18 13:25 +1100
Re: local variable "Elizabeth D. Rather" <erather@forth.com> - 2015-03-17 16:43 -1000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-18 04:09 +0100
Re: local variable "Elizabeth D. Rather" <erather@forth.com> - 2015-03-17 17:55 -1000
Re: local variable "HAA" <someone@microsoft.com> - 2015-03-20 22:28 +1100
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-20 15:43 +0100
Identifying self interest (was Re: local variable) "Alex McDonald" <blog@rivadpm.com> - 2015-03-20 15:20 +0000
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2015-03-18 08:48 +0000
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2015-09-16 18:55 +0000
Re: local variable hughaguilar96@gmail.com - 2015-09-16 22:03 -0700
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-17 14:18 +0000
Re: local variable albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-17 16:24 +0000
Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-03-17 16:34 +0000
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-18 14:32 +0000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-17 20:08 +0100
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-18 15:21 +0000
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-16 15:36 +0000
Re: local variable hughaguilar96@gmail.com - 2015-03-16 10:09 -0700
Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-03-16 20:24 +0000
Re: local variable "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-03-16 19:00 -0400
Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-03-17 12:06 +0000
Re: local variable stephen@mpeforth.com (Stephen Pelc) - 2015-03-17 14:37 +0000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-17 18:58 +0100
Re: local variable Doug Hoffman <glidedog@gmail.com> - 2015-03-17 08:55 -0400
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-17 14:15 +0000
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-17 16:54 +0000
Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-03-17 17:45 +0000
Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-17 20:14 +0100
Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-20 15:06 +0000
Re: local variable hughaguilar96@gmail.com - 2015-03-20 16:14 -0700
Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-03-21 09:47 +0000
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
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2015-03-18 05:04 +0000
Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2016-02-08 16:09 +0000
Ignore the standard Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-03-18 04:09 -0700
Re: Ignore the standard Doug Hoffman <glidedog@gmail.com> - 2015-03-18 07:26 -0400
Re: Ignore the standard "WJ" <w_a_x_man@yahoo.com> - 2015-03-20 17:31 +0000
Re: Ignore the standard Doug Hoffman <glidedog@gmail.com> - 2015-03-20 17:41 -0400
Re: Ignore the standard "Elizabeth D. Rather" <erather@forth.com> - 2015-03-20 14:26 -1000
Re: Ignore the standard Doug Hoffman <glidedog@gmail.com> - 2015-03-21 06:00 -0400
Re: Ignore the standard hughaguilar96@gmail.com - 2015-03-21 15:11 -0700
Re: Ignore the standard Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-21 02:49 +0100
Re: Ignore the standard Doug Hoffman <glidedog@gmail.com> - 2015-03-21 06:04 -0400
Re: Ignore the standard "Alex McDonald" <blog@rivadpm.com> - 2015-03-18 16:05 +0000
Re: Ignore the standard "WJ" <w_a_x_man@yahoo.com> - 2015-03-20 17:13 +0000
Re: local variable foxaudioresearch@gmail.com - 2015-07-05 08:44 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-11 11:03 +0200 |
| Message-ID | <mnqm48$vpt$1@newsreader4.netcologne.de> |
| In reply to | #40494 |
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]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-11 11:11 +0200 |
| Message-ID | <mnqmio$vvr$1@newsreader4.netcologne.de> |
| In reply to | #40517 |
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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-12 16:43 -0700 |
| Message-ID | <40104b8f-b316-492f-9339-077cfbc50dee@googlegroups.com> |
| In reply to | #40519 |
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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-11 15:14 +0000 |
| Message-ID | <2015Jul11.171433@mips.complang.tuwien.ac.at> |
| In reply to | #40517 |
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]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-07-11 17:57 -0700 |
| Message-ID | <ddb326bc-4a6c-48ef-bf5f-591d38a83a29@googlegroups.com> |
| In reply to | #40527 |
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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-12 15:32 +0000 |
| Message-ID | <2015Jul12.173226@mips.complang.tuwien.ac.at> |
| In reply to | #40541 |
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]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-10 13:13 +0100 |
| Message-ID | <mnocr5$lev$1@dont-email.me> |
| In reply to | #40480 |
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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-10 21:48 -0700 |
| Message-ID | <0ffa0228-204b-49f9-8181-7e3f33df6ef2@googlegroups.com> |
| In reply to | #40389 |
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]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-07-05 03:47 -0700 |
| Message-ID | <d4017005-4c47-4838-a4a0-bb8b291ca6cf@googlegroups.com> |
| In reply to | #40300 |
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]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-05 04:15 -0700 |
| Message-ID | <3cd951f1-38e8-486a-86dc-e2b95ff669c6@googlegroups.com> |
| In reply to | #40305 |
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]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-05 04:27 -0700 |
| Message-ID | <9657d26f-2bc7-4a70-8e7a-a9d9d7ac1a74@googlegroups.com> |
| In reply to | #40306 |
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]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-05 04:39 -0700 |
| Message-ID | <0fa6aff1-52d9-4e10-bdc7-f5aa089a109d@googlegroups.com> |
| In reply to | #40307 |
> 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]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-07-05 07:08 -0700 |
| Message-ID | <16f25b94-5a8d-4978-acdc-02c40c9c53ce@googlegroups.com> |
| In reply to | #40306 |
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] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-03-18 05:04 +0000 |
| Message-ID | <meb11d$jve$1@dont-email.me> |
| In reply to | #37262 |
grobibi wrote:
> Hello,
> There is something I don't understand with local variable with gforth.
> A variable defined like this :
>
> variable x 10
>
> will have a general scope. How can I get a
> local scope for a variable inside a word definition ? Is it possible ?
>
Oforth:
x is the local variable.
func: pair-with-squares(list)
{|x| list map( #[ -> x [x, x x *]])}
> [2,3,4] pair-with-squares println
[[2, 4], [3, 9], [4, 16]]
ok
> pair-with-squares([5,6,7,8]) println
[[5, 25], [6, 36], [7, 49], [8, 64]]
ok
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-02-08 16:09 +0000 |
| Message-ID | <n9aejb$g3f$1@dont-email.me> |
| In reply to | #37372 |
WJ wrote:
> grobibi wrote:
>
> > Hello,
> > There is something I don't understand with local variable with gforth.
> > A variable defined like this :
> >
> > variable x 10
> >
> > will have a general scope. How can I get a
> > local scope for a variable inside a word definition ? Is it possible ?
> >
>
> Oforth:
>
> x is the local variable.
>
> func: pair-with-squares(list)
> {|x| list map( #[ -> x [x, x x *]])}
>
>
> > [2,3,4] pair-with-squares println
> [[2, 4], [3, 9], [4, 16]]
> ok
> > pair-with-squares([5,6,7,8]) println
> [[5, 25], [6, 36], [7, 49], [8, 64]]
> ok
For OFORTH version V0.9.23.1:
: pair-with-squares(list)
|x| list map( #[ -> x [x, x x *]]) ;
> [2,3,4] pair-with-squares .
[[2, 4], [3, 9], [4, 16]] ok
> pair-with-squares([5,6,7,8]) println
[[5, 25], [6, 36], [7, 49], [8, 64]]
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-03-18 04:09 -0700 |
| Subject | Ignore the standard |
| Message-ID | <ca299775-3489-48b2-937c-aaef7428e235@googlegroups.com> |
| In reply to | #37262 |
Regarding locals I will ignore the standard as much as I can.
The committee screwed it up with LOCALS| in the first place.
The new standard makes it even worse. The best solution IMHO would be
to ignore both standards regarding locals and continue using {..}
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2015-03-18 07:26 -0400 |
| Subject | Re: Ignore the standard |
| Message-ID | <55096102$0$292$14726298@news.sunsite.dk> |
| In reply to | #37385 |
On 3/18/15 7:09 AM, Stefan Mauerhofer wrote:
> Regarding locals I will ignore the standard as much as I can. The
> committee screwed it up with LOCALS| in the first place. The new
> standard makes it even worse. The best solution IMHO would be to
> ignore both standards regarding locals and continue using {..}
If there were no standards I wouldn't be using Forth. The good people
who donate(d) so much of their time and effort towards the ANS and 200x
standards deserve our thanks and support, even if one might not agree
with every last detail. It's truly a thankless job.
-Doug
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-03-20 17:31 +0000 |
| Subject | Re: Ignore the standard |
| Message-ID | <mehlh7$oku$1@dont-email.me> |
| In reply to | #37388 |
Doug Hoffman wrote:
> On 3/18/15 7:09 AM, Stefan Mauerhofer wrote:
> > Regarding locals I will ignore the standard as much as I can. The
> > committee screwed it up with LOCALS| in the first place. The new
> > standard makes it even worse. The best solution IMHO would be to
> > ignore both standards regarding locals and continue using {..}
>
> If there were no standards I wouldn't be using Forth.
That makes no sense.
It would only make sense if you were a slavish fanatic
who considers the "standard" his holy scriptures.
What if the "standard" didn't allow floats? Would you say
that using floating point math is evil?
What if the "standard" limited integers to 16 bits.
Would you then say that 32-bit integers are the work of the devil?
The number of people who seriously program in ANS Forth is miniscule
compared to the number that program in Perl or Python or Ruby,
languages which are not crippled by an obsolete, clunky ANS "standard".
Paul Graham, the well-known author of Lisp books, said this about
ANS Lisp: "The good news is, it's not Lisp that sucks, but Common Lisp."
The good news is, it's not Forth that sucks, but ANS Forth.
To strive to preserve the crippling ANS standard or to replace it
with another backward standard sanctioned by Forth, Inc., is to strive
to destroy Forth.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2015-03-20 17:41 -0400 |
| Subject | Re: Ignore the standard |
| Message-ID | <550c941d$0$280$14726298@news.sunsite.dk> |
| In reply to | #37486 |
On 3/20/15 1:31 PM, WJ wrote:
> Doug Hoffman wrote:
>
>> On 3/18/15 7:09 AM, Stefan Mauerhofer wrote:
>>> Regarding locals I will ignore the standard as much as I can. The
>>> committee screwed it up with LOCALS| in the first place. The new
>>> standard makes it even worse. The best solution IMHO would be to
>>> ignore both standards regarding locals and continue using {..}
>>
>> If there were no standards I wouldn't be using Forth.
>
> That makes no sense.
It means that I can easily make use of code written by someone else. It
also means that I can switch Forth compilers, such as if the creator of
the Forth I was using stops supporting it. I think that makes a lot of
sense.
> It would only make sense if you were a slavish fanatic
> who considers the "standard" his holy scriptures.
No one is forced to follow the standard. But it does provide stability
and a starting place. But trying new "non-standard" things and showing
them to the Forth community is one way to get positive change to the
standard. This has happened a lot. This is, in fact, exactly what
happened with the LOCALS| ... | vs { ... } syntax that you are
responding to above. Whether it should be { ... } or {: ... :} is still
being debated somewhat but that is a rather minor point in this case.
> What if the "standard" didn't allow floats? Would you say
> that using floating point math is evil?
>
> What if the "standard" limited integers to 16 bits.
> Would you then say that 32-bit integers are the work of the devil?
There are a world of ifs to live in. Neither of the two you mention exist.
> The number of people who seriously program in ANS Forth is miniscule
> compared to the number that program in Perl or Python or Ruby,
> languages which are not crippled by an obsolete, clunky ANS "standard".
Tell us what you think is wrong with it and feel free to offer
suggestions for improvement. Break your pattern of never responding to
a question put directly to you. Are you able to do that?
> Paul Graham, the well-known author of Lisp books, said this about
> ANS Lisp: "The good news is, it's not Lisp that sucks, but Common Lisp."
>
> The good news is, it's not Forth that sucks, but ANS Forth.
>
> To strive to preserve the crippling ANS standard or to replace it
> with another backward standard sanctioned by Forth, Inc., is to strive
> to destroy Forth.
Instead of just parroting the mantra that something is "bad", provide
reason and rationale. You might be surprised at the result if your
reasoning is sound and presented in a well thought out manner.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-03-20 14:26 -1000 |
| Subject | Re: Ignore the standard |
| Message-ID | <4Y6dndfLmNI0J5HInZ2dnUU7-N-dnZ2d@supernews.com> |
| In reply to | #37492 |
On 3/20/15 11:41 AM, Doug Hoffman wrote:
> On 3/20/15 1:31 PM, WJ wrote:
>> Doug Hoffman wrote:
...
>>> If there were no standards I wouldn't be using Forth.
>>
>> That makes no sense.
>
> It means that I can easily make use of code written by someone else. It
> also means that I can switch Forth compilers, such as if the creator of
> the Forth I was using stops supporting it. I think that makes a lot of
> sense.
>
>> It would only make sense if you were a slavish fanatic
>> who considers the "standard" his holy scriptures.
>
> No one is forced to follow the standard. But it does provide stability
> and a starting place. But trying new "non-standard" things and showing
> them to the Forth community is one way to get positive change to the
> standard. This has happened a lot. This is, in fact, exactly what
> happened with the LOCALS| ... | vs { ... } syntax that you are
> responding to above. Whether it should be { ... } or {: ... :} is still
> being debated somewhat but that is a rather minor point in this case.
>
>> What if the "standard" didn't allow floats? Would you say
>> that using floating point math is evil?
>>
>> What if the "standard" limited integers to 16 bits.
>> Would you then say that 32-bit integers are the work of the devil?
>
> There are a world of ifs to live in. Neither of the two you mention exist.
>
In fact, FORTH83, the predecessor of ANS Forth, didn't allow floats and
limited single-length integers (as well as addresses) to 16 bits. It
also mandated Indirect Threaded implementation. ANS Forth fixed all
those problems (and added the ability to handle OS files portably, as
well as other features).
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]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web