Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #25242 > unrolled thread
| Started by | Ian van Breda <igvb@btopenworld.com> |
|---|---|
| First post | 2013-08-16 11:59 +0100 |
| Last post | 2013-08-23 17:37 +1000 |
| Articles | 8 on this page of 88 — 16 participants |
Back to article view | Back to comp.lang.forth
LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-16 11:59 +0100
Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 12:31 +0100
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:31 +0000
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 21:50 +0200
Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-17 08:51 +0000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-18 20:10 +0100
Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-18 23:32 +0200
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-18 15:47 -0700
Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-19 15:10 +0100
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 09:46 +0000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-22 20:15 +0100
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 07:17 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 14:18 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 10:25 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 15:39 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 11:26 -0500
Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-20 11:25 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 10:05 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-21 14:38 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 11:48 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-21 16:50 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:18 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-22 12:33 +0000
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-22 15:26 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:25 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:24 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:12 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 01:22 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 02:56 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 01:49 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:52 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 08:10 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:00 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 13:46 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 03:01 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-24 03:24 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 12:51 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-25 11:44 -0700
Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:42 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:24 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 11:50 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 08:13 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 13:55 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:05 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-24 10:36 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 13:05 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 22:44 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 04:29 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 20:15 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 15:51 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 23:27 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-26 03:19 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-26 20:38 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-27 11:52 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-28 03:52 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-28 11:55 -0500
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-26 11:36 +0000
Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-21 10:36 -0700
Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-21 17:22 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:34 -0500
Re: LOCALS| and {: mhx@iae.nl - 2013-08-21 23:05 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 03:15 -0500
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-22 14:49 -0700
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:07 +0200
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-26 20:51 -0700
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-27 15:55 +0200
Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 10:22 -0700
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-27 17:33 +0000
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-27 23:02 +0000
Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 22:02 -0700
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-27 11:08 -0700
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-27 21:16 -0700
Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:56 +0000
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 20:10 +0000
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:49 +0000
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-20 07:14 +0000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-21 10:28 +0100
Re: LOCALS| and {: "Elizabeth D. Rather" <erather@forth.com> - 2013-08-18 10:04 -1000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-19 20:08 +0100
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:54 +0000
Re: LOCALS| and {: Mark Wills <markrobertwills@yahoo.co.uk> - 2013-08-20 02:19 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 04:37 -0500
Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-17 13:58 +0200
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-17 18:49 -0700
Re: LOCALS| and {: "Ed" <invalid@invalid.com> - 2013-08-23 17:37 +1000
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-08-18 10:04 -1000 |
| Message-ID | <AY2dnQqZh9cOt4zPnZ2dnUVZ_h6dnZ2d@supernews.com> |
| In reply to | #25278 |
On 8/16/2013 10:51 PM, Stephen Pelc wrote:
> On Fri, 16 Aug 2013 11:59:02 +0100, Ian van Breda
> <igvb@btopenworld.com> wrote:
>
>> Having got used to using LOCALS| it is somewhat confusing to find
>> that names are reversed in {: .
>
> The notation is nearly 30 years old now. Informed rumour tells
> me that it was originally designed by Don Colbourn. When I
> measured the use of LOCALS| ... | and { ... } in systems that
> have both, the brace notation was used far more than than
> LOCALS|.
>
> I suspect that the popularity is caused by the brace notation
> looking like a stack comment. The extra features are nice too.
At the time locals were being considered by the Forth94 TC, Don's
implementation in MacForth was the only version of locals in public use,
and had a very large number of users. The issue of stack order for
LOCALS| was very contentious: the only issue in the 6 years we worked on
the standard on which no consensus (which we defined as a min. 80%
majority) could be reached. Ultimately, the desire to embrace a
technology already proven in use outweighed the desire to have what many
felt was a more "logical" argument order, but the margin was a very few
votes.
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]
| From | Ian van Breda <igvb@btopenworld.com> |
|---|---|
| Date | 2013-08-19 20:08 +0100 |
| Message-ID | <CE382BB1.39F1%igvb@btopenworld.com> |
| In reply to | #25291 |
Elizabeth D. Rather wrote on 18/08/2013 21:04:
>
> At the time locals were being considered by the Forth94 TC, Don's
> implementation in MacForth was the only version of locals in public use,
> and had a very large number of users. The issue of stack order for
> LOCALS| was very contentious: the only issue in the 6 years we worked on
> the standard on which no consensus (which we defined as a min. 80%
> majority) could be reached. Ultimately, the desire to embrace a
> technology already proven in use outweighed the desire to have what many
> felt was a more "logical" argument order, but the margin was a very few
> votes.
>
I find no problem with the order of either LOCALS| or {: . However, having
used LOCALS| in ANS Forth from the *start*, I have made extensive use of it
in my own code. I have no problem with the order of the names. There is
far too much code, though, to make the change from LOCALS| to {: feasible.
Far more problematical in ANS is the question of wordslist's and
VOCABULARY's (see my posting under heading of Namespaces). You don't need
the TRANSENT and NO-TRANSIENT, as these are use only in ASSEMBLER and ONLY
is not needed in this scheme. I use an ANS-compatibility file to make the
code ANS-compatible (I use a software switch between ANS and non-ANS
compatibility).
Ian
P.S. You may remember the Forth Inc systems for RGO, still going strong now
in a Mac ANS version (Mac Classic).
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-08-20 01:54 +0000 |
| Message-ID | <5212cc5b$0$26903$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #25310 |
In article <CE382BB1.39F1%igvb@btopenworld.com>,
Ian van Breda <igvb@btopenworld.com> wrote:
>Elizabeth D. Rather wrote on 18/08/2013 21:04:
>
>>
>> At the time locals were being considered by the Forth94 TC, Don's
>> implementation in MacForth was the only version of locals in public use,
>> and had a very large number of users. The issue of stack order for
>> LOCALS| was very contentious: the only issue in the 6 years we worked on
>> the standard on which no consensus (which we defined as a min. 80%
>> majority) could be reached. Ultimately, the desire to embrace a
>> technology already proven in use outweighed the desire to have what many
>> felt was a more "logical" argument order, but the margin was a very few
>> votes.
>>
>I find no problem with the order of either LOCALS| or {: . However, having
>used LOCALS| in ANS Forth from the *start*, I have made extensive use of it
>in my own code. I have no problem with the order of the names. There is
>far too much code, though, to make the change from LOCALS| to {: feasible.
Come on.
It is easy enough to write a filter to change that automatically, which
means it is feasible.
>
>Far more problematical in ANS is the question of wordslist's and
>VOCABULARY's (see my posting under heading of Namespaces). You don't need
>the TRANSENT and NO-TRANSIENT, as these are use only in ASSEMBLER and ONLY
>is not needed in this scheme. I use an ANS-compatibility file to make the
>code ANS-compatible (I use a software switch between ANS and non-ANS
>compatibility).
>
>Ian
>
>P.S. You may remember the Forth Inc systems for RGO, still going strong now
>in a Mac ANS version (Mac Classic).
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2013-08-20 02:19 -0700 |
| Message-ID | <f6295343-fc28-4ec5-bb10-042ed0392f5d@googlegroups.com> |
| In reply to | #25278 |
For what it's worth, my implementation of locals is a kind of halfway-house between locals| and {:
* Locals are declared with names
* They are *not* populated from the stack
* They are loaded with the word SET
* Because SET is used to set a locals' value, locals can be initialised in any order; the order in which they appear in the declaration is irrelevant.
* Locals can span lines
* No restriction on number of locals required. If no locals used, no space allocated
* Uses a separate locals stack; return stack still available for >R and R> etc
* Locals occupy no dictionary space at all, not even during compilation. Their names are turned into a hash at compile time, and the hash is used to locate their position on the locals stack.
: THING ( a b c -- )
LOCALS{ fred sally john }
SET JOHN \ c to john
SET SALLY \ b to sally
DUP * SET FRED \ a squared to fred
...
;
I took the view that I don't/won't always want all my locals to be *automatically* populated from the stack - I often only want a local to be used as an accumulator, for example. Using SET seemed like a simple solution. I would have used TO rather than SET, but in my memory constrained system (32K) TO is in EPROM and always available (for VALUES) but locals support is loaded from blocks if required.
If anyone is interested, there's a write-up here:
http://turboforth.net/locals.html
It includes implementation details. Maybe some people would like it. I personally find it extrememely comfortable to use, and totally painless, requiring no brain power at all from the user.
FWIW:
\ An implementation of local variables.
\ Not ANS compatible.
\ Local variables are declared with the word LOCALS{ followed by a list
\ of variable names, followed by a closing }
\ For example:
\ TEST ( -- ) locals{ a b c } ... ... ... ;
\ The local variables are initialised to 0 upon creation.
\
\ Locals are referenced in code with their names.
\ Locals may be written to with SET and +SET. E.g.
\ : TEST ( x y z -- ) locals{ a b c } set c set b set a ;
\ The above example initialises the local variables a, b and c from the
\ data on the data stack. Z goes to c, y to b, and x to a.
\
\ Here is another example:
\ : TEST ( x y z -- z(x+y) )
\ locals{ x y z } set z set y set x
\ x y + z * ;
\
\ Where recursion is used with a definition that contains locals, each
\ instance of the definition shall inherit its own set of new locals.
\ These will be automatically de-allocated when the recursion un-winds.
\ Locals consume no dictionary space at all. Their names are temporarily
\ hashed during compilation only. After that their names are not required.
\ The hash table is set to the end of RAM (see dictAddr). There is
\ room for 14 locals per definition as currently set.
\ The locals stack sits immediately above the hash table and grows
\ towards lower memory addresses (the hash table grows to higher addresses).
\
\ During execution, locals add very little overhead: 1 call to allocate
\ the appropriate number of local-stack cells at the beginning of a colon
\ definition, and a similar call to de-allocate at the end of a colon
\ definition.
\ References to locals are compiled as literals representing an offset
\ into the locals stack, plus a call to @local
0 value locals? \ true if a colon-def has locals
0 value localCount \ number of locals in a colon def
0 value localOffset
$FFE0 VALUE dictAddr \ address of start of local dictionary
$A006 @ VALUE _FIND \ save contents of FIND vector
dictAddr VALUE _LS \ top of local stack pointer
\ note: the locals stack and the locals dictionary grow away from each
\ other. There is a pre-decrement on local stack operations, therefore
\ it is safe to set the locals stack to the same address as the locals
\ dictionary, as they grow away from each other.
: (freeLocals) ( n -- ) \ runtime code to de-allocate n locals
CELLS +TO _LS ;
: freeLocals ( n -- ) \ compile runtime code to free n locals
COMPILE LIT , COMPILE (freeLocals) FALSE TO locals? ;
: (allotLocals) ( n -- ) \ runtime code to allot n locals on locals stack
\ stack grows towards lower memory addresses
CELLS DUP NEGATE +TO _LS _LS SWAP 0 FILL ( intialise n locals to 0) ;
: allotLocals ( n -- ) \ compile run-time code to allot n locals
COMPILE LIT , COMPILE (allotLocals) TRUE TO locals? ;
: >HASH ( c-addr len -- u)
\ hashes a string using the CRC-16 algorithm
$FFFF \ intial CRC16
-ROT \ move it out of the way
OVER + SWAP DO \ for each byte in the string
I C@ XOR \ xor with CRC16
8 0 DO \ for 8 bits in the byte
DUP 1 AND \ note the LSB prior to shift
SWAP 1 >> \ shift the CRC16
SWAP IF
$A001 XOR \ if LSB was 1 then apply polynomial
THEN
LOOP
LOOP ;
: (LOCAL) ( addr len -- )
?DUP IF \ is a local. Add to fleeting locals dictionary:
>HASH \ hash the variable name
dictAddr localCount CELLS + ! \ store hash in local dictionary
1 +TO localCount \ increment number of locals
ELSE \ end of locals list
DROP
localCount allotLocals
THEN ;
: LOCALS{ ( "name...name }" --
0 TO localCount
BEGIN
BL WORD OVER C@
ASCII } - OVER 1 - OR
WHILE \ while | character not detected
(LOCAL) \ add local variable to locals dictionary
REPEAT
2DROP 0 0 (LOCAL) \ end local dictionary processing
; IMMEDIATE
: @local ( index -- n ) \ fetch a local from the local stack
_LS + @ ;
: compileLocal ( -- )
COMPILE LIT localOffset 1- CELLS , COMPILE @local ;
: findLocal ( addr len - offset+1|0)
\ search locals dictionary for word and return offset into
\ locals stack+1 if found or 0 if not found
>HASH 0 SWAP
localCount 0 DO
dictAddr I CELLS + @ OVER = IF
SWAP DROP I 1+ SWAP LEAVE
THEN
LOOP DROP
DUP TO localOffset ;
0 VALUE addr
0 VALUE len
: ^FIND ( addr len -- cfa flag )
2DUP TO len TO addr
_FIND EXECUTE DUP 0= IF
STATE @ IF
locals? IF
2DROP addr len findLocal IF
['] compileLocal 1
ELSE
0 0
THEN
THEN
THEN
THEN ;
: localNotFound ( --)
CR ." Error: Local not found." FALSE to locals? ABORT ;
: (SET) ( value offset -- )
\ at runtime, set a local variable to to value value
_LS + ! ;
: (+SET) ( value offset -- )
\ at runtime add a value to a local variable
_LS + +! ;
: doSET ( xt "local" value -- )
BL WORD findLocal IF
COMPILE LIT localOffset 1- CELLS , ,
ELSE
localNotFound
THEN ;
: SET ( "local" value -- xt ) \ write the value to the local variable
['] (SET) doSet ; IMMEDIATE
: +SET ( "local" value -- xt ) \ add the value to the local variable
['] (+SET) doSet ; IMMEDIATE
: ; locals? IF localCount freeLocals THEN [COMPILE] ; ; IMMEDIATE
' ^FIND $A006 ! \ re-vector FIND to use our FIND first
There. I posted some Forth code this month ;-)
Mark
Mark
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-20 04:37 -0500 |
| Message-ID | <c7-dnQPRjtMhpY7PnZ2dnUVZ_t-dnZ2d@supernews.com> |
| In reply to | #25315 |
Mark Wills <markrobertwills@yahoo.co.uk> wrote: > * They are *not* populated from the stack > * They are loaded with the word SET > * Because SET is used to set a locals' value, locals can be > initialised in any order; the order in which they appear in the > declaration is irrelevant. I think this is more a matter of coding style. Of course, a local can be used as an accumulator, but a common style has locals mostly read- only. So, on entry to a word, a bunch of stack cells are given names, and TO is not much used. The "auto-initialize" feature of locals makes sense in this context. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2013-08-17 13:58 +0200 |
| Message-ID | <1ajkd0smn41jf$.se6to68ap4uc.dlg@40tude.net> |
| In reply to | #25242 |
Op Fri, 16 Aug 2013 11:59:02 +0100 schreef Ian van Breda:
> Having got used to using LOCALS| it is somewhat confusing to find that names
> are reversed in {:
Which one looks more natural
: one 1 2 3 .s locals| a b c | a b c .s drop 2drop ;
: two 1 2 3 .s {: a b c :} a b c .s drop 2drop ;
one ( 1 2 3 ) ( 3 2 1 )
two ( 1 2 3 ) ( 1 2 3 )
As always, the top of the stack in Forth is on the right, not left.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2013-08-17 18:49 -0700 |
| Message-ID | <9ce34c0a-cf8d-45b0-818b-b5eb92717d54@googlegroups.com> |
| In reply to | #25242 |
On Friday, August 16, 2013 3:59:02 AM UTC-7, Ian van Breda wrote:
> Having got used to using LOCALS| it is somewhat confusing to find that names
> are reversed in {: .
LOCALS| was totally screwed up! Getting used to it, is essentially the same as getting used to a bug. Having the names in the order given in {: is much better.
I don't like the name {: though, as that is awfully ugly --- in my novice package I called it { which is the most common name for it.
> Although not explicitly stated, it appears that {: :}
> is intended to be used at the front of definitions.
It can have code in front of it. It can't be inside of a control-structure though (in the C language you can define locals inside of control-structures).
> Normally, this would need three zeroes preceding the three val variables
In my { in my novice package, I initialize the locals that are after the | to zero. I argued that this should be done in {: too --- but Anton refused to listen, and said that they had to be initialized to an undefined state. That make no sense to me --- they have to initialized to something, so why not define what it is, and why not make it zero which is usually what the user wants?
> One definition that is useful is +TO which increments a variable LOCALS|
> variable.
>
> moveCount BufferCount + TO BufferCount
>
> is better as
>
> moveCount +TO BufferCount
>
> This is particularly in counting of indefinite loops.
I have +TO in my novice package.
Note that in the language I am designing, I am getting rid of TO altogether --- locals will be like variables, in that they are accessed with @ and ! --- and there won't be any VALUEs anymore.
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2013-08-23 17:37 +1000 |
| Message-ID | <kv73c8$gfv$1@speranza.aioe.org> |
| In reply to | #25242 |
Ian van Breda wrote:
> ...
> Having got used to using LOCALS| it is somewhat confusing to find that names
> are reversed in {: .
LOL. Because that's *precisely* the argument the vocal make against
LOCALS| ... namely they couldn't (or rather wouldn't) get used to it.
There's a c.l.f. post written in the mid 90's calling for everyone to boycott
LOCALS| . That person now sits on the 200x panel along with similarly
minded dislikers.
I don't recall many instances in which boycotts have been called on c.l.f.
To my knowledge there has only been two - LOCALS| and myself. Such
is the influence some here believe they wield :)
I don't use locals - having abandoned them after reading a post by Jeff Fox.
He didn't call for boycotts. He didn't need an army of supporters or a
Standard to tell him what experience was showing him every day.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.forth
csiph-web