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

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

local variable

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

Contents

  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 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 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 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 "WJ" <w_a_x_man@yahoo.com> - 2015-03-18 05:04 +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

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

#37366

Stephen Pelc wrote:
> [...]
> The brace notation was complete and had usage history long before the
> ANS locals process started. We added LOCALS| just for ANS compliance.

The fact remains ANS TC voted for Colburn's  LOCALS|  over the braces
notation.  They must have had their reasons.

> >The proof a Standard is whether anyone is using it.  Do you use {: ... :} ?
>
> [...]
>  Since the meeting at which Forth 200x adoped
> {: ... :} I have used it.

You must be the exception.

It's my observation  {: ... :}  is just as unpopular with brace users as was
LOCALS| .  It suggests locals in Forth is as fractured as ever with
appearance over-ruling substance.  ANS was ambivalent about introducing
locals.  Their worst fears appear to have come true.

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

#37367

On 3/17/15 4:25 PM, HAA wrote:
> Stephen Pelc wrote:
>> [...]
>> The brace notation was complete and had usage history long before the
>> ANS locals process started. We added LOCALS| just for ANS compliance.
>
> The fact remains ANS TC voted for Colburn's  LOCALS|  over the braces
> notation.  They must have had their reasons.

It was the most hotly and extensively debated issue of the entire 
process. The TC was almost evenly divided on the issue. The argument in 
favor of LOCALS| and its argument order was that it had been implemented 
in MacForth for years and there were literally thousands of copies in 
use, and much code dependent on it. At that time, no one on the 
committee had more than experimental code using the other order. 
Ultimately, the TC was unwilling to invalidate that much existing code.

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]

#37368

Elizabeth D. Rather wrote:

> On 3/17/15 4:25 PM, HAA wrote:
>> Stephen Pelc wrote:
>>> [...]
>>> The brace notation was complete and had usage history long before the
>>> ANS locals process started. We added LOCALS| just for ANS compliance.
>>
>> The fact remains ANS TC voted for Colburn's  LOCALS|  over the braces
>> notation.  They must have had their reasons.
> 
> It was the most hotly and extensively debated issue of the entire
> process. The TC was almost evenly divided on the issue. The argument in
> favor of LOCALS| and its argument order was that it had been implemented
> in MacForth for years and there were literally thousands of copies in
> use, and much code dependent on it. At that time, no one on the
> committee had more than experimental code using the other order.
> Ultimately, the TC was unwilling to invalidate that much existing code.

Like any non-standard code, that code isn't "invalidated" by a TC decision 
for a different proposal.  It is just the same non-standard stuff as it was 
before.  In so far one could say that the current {: :} standard 
"invalidates" all the programs which actually use the { } braces notation 
without colon, and doing that would be no way.  The {: :} notation is a 
compromise between all those people who used the braces notaion and Forth 
Inc., which ignored the braces notation, and instead used braces for multi-
line comments.  I don't think it will really catch on: The people who used 
the braces notation on Forths who had it before, will continue to use it, 
and the systems will continue to offer that.

I've implemented locals in bigForth in 1992, using the braces notation.  In 
1993, I added ANS locals; I did never use them.  I haven't heard of the 
locals| notation before ANS; however, I did hear of the braces notation, 
must have been right here in comp.lang.forth.

The Forth200x committee wouldn't have accepted a proposal with only a slight 
majority.  That is way too far off consensus to be acceptable.  Usually, 
with two nays, we feel it's no longer acceptable.  This is a conservative 
strategy, and nobody forces us to be fast.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#37371

On 3/17/15 5:09 PM, Bernd Paysan wrote:
> Elizabeth D. Rather wrote:
>
>> On 3/17/15 4:25 PM, HAA wrote:
>>> Stephen Pelc wrote:
>>>> [...]
>>>> The brace notation was complete and had usage history long before the
>>>> ANS locals process started. We added LOCALS| just for ANS compliance.
>>>
>>> The fact remains ANS TC voted for Colburn's  LOCALS|  over the braces
>>> notation.  They must have had their reasons.
>>
>> It was the most hotly and extensively debated issue of the entire
>> process. The TC was almost evenly divided on the issue. The argument in
>> favor of LOCALS| and its argument order was that it had been implemented
>> in MacForth for years and there were literally thousands of copies in
>> use, and much code dependent on it. At that time, no one on the
>> committee had more than experimental code using the other order.
>> Ultimately, the TC was unwilling to invalidate that much existing code.
>
> Like any non-standard code, that code isn't "invalidated" by a TC decision
> for a different proposal.  It is just the same non-standard stuff as it was
> before.  In so far one could say that the current {: :} standard
> "invalidates" all the programs which actually use the { } braces notation
> without colon, and doing that would be no way.  The {: :} notation is a
> compromise between all those people who used the braces notaion and Forth
> Inc., which ignored the braces notation, and instead used braces for multi-
> line comments.  I don't think it will really catch on: The people who used
> the braces notation on Forths who had it before, will continue to use it,
> and the systems will continue to offer that.
>
> I've implemented locals in bigForth in 1992, using the braces notation.  In
> 1993, I added ANS locals; I did never use them.  I haven't heard of the
> locals| notation before ANS; however, I did hear of the braces notation,
> must have been right here in comp.lang.forth.
>
> The Forth200x committee wouldn't have accepted a proposal with only a slight
> majority.  That is way too far off consensus to be acceptable.  Usually,
> with two nays, we feel it's no longer acceptable.  This is a conservative
> strategy, and nobody forces us to be fast.

That was also the rule for the ANS Forth TC, but after 6 years during 
which we failed to obtain a consensus on this issue while all other 
outstanding issues had been resolved, we reluctantly accepted it.

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]

#37467

Bernd Paysan wrote:
> ...
> The Forth200x committee wouldn't have accepted a proposal with only a slight
> majority.  That is way too far off consensus to be acceptable.  Usually,
> with two nays, we feel it's no longer acceptable.  This is a conservative
> strategy, and nobody forces us to be fast.

Effectively reversing a decision made in a previous Standard for no other reason
than some didn't like the order of the arguments is a strategy that speaks of
self-interest above Forth's.

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

#37470

HAA wrote:
> Effectively reversing a decision made in a previous Standard for no other
> reason than some didn't like the order of the arguments is a strategy that
> speaks of self-interest above Forth's.

We didn't throw out LOCALS|.  We just added the way more popluar {, though 
with a small change in the name.

A standard is about writing down what common practice is.  Forth users are 
usually pretty independent thinkers; if Forth would be the fad of the year, 
we probably would have way more lemmings following whatever the standard 
tells them.  We don't.  Therefore, the standard team isn't that much in a 
position to force things down people's throat.

People simply didn't accept LOCALS|, and used the non-standard { notation 
instead.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#37471 — Identifying self interest (was Re: local variable)

on 20/03/2015 11:28:53, "HAA" wrote:
> Bernd Paysan wrote:
>> ...
>> The Forth200x committee wouldn't have accepted a proposal with only a slight
>> majority.  That is way too far off consensus to be acceptable.  Usually,
>> with two nays, we feel it's no longer acceptable.  This is a conservative
>> strategy, and nobody forces us to be fast.
> 
> Effectively reversing a decision made in a previous Standard for no
> other reason than some didn't like the order of the arguments is a
> strategy that speaks of self-interest above Forth's.

As someone who works on quite a lot of standards committees, I'm
fascinated by the casual observer's characterisation of how things work,
and the judgements that get made.

This is an interesting observation; someone (perhaps more than one) had a
strategy that put their self- interest above the interests of Forth. 

Hmmm. 

What is the interest of Forth? Does Forth have any interests, or even a
corpreal manifestation? When people say things like this, are they
meaning that others interests weren't aligned to their self- interests?
Or is this an attempt to protect the interests & position of the previous
standards committee?

Perhaps it's because it's difficult to say "I don't agree, and here's
why", and far easier to say "Blasphemy! You've placed yourself above
God's word!" and burn people for it.

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

#37377

HAA wrote:

> Stephen Pelc wrote:
> > [...]
> > The brace notation was complete and had usage history long before the
> > ANS locals process started. We added LOCALS| just for ANS compliance.
> 
> The fact remains ANS TC voted for Colburn's  LOCALS|  over the braces
> notation.  They must have had their reasons.

Even if they had their reasons, that does not mean that they
had good reasons.

Their reasons might have been atrocious.

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

#37331

"HAA" <someone@microsoft.com> writes:
>The proof a Standard is whether anyone is using it.  Do you use {: ... :} ?

I have used it more often than LOCALS|.  However, most of the time I
still use { ... } for now, because {: ... :} is still recently
introduced, and more of the systems I use have { ... } than {: ... :}.
In the next few years that should change, as systems should pick up {:
... :}, including some that don't have { ... }.

- 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 2014: http://www.euroforth.org/ef14/

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

#37333

In article <2015Mar17.151849@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"HAA" <someone@microsoft.com> writes:
>>The proof a Standard is whether anyone is using it.  Do you use {: ... :} ?
>
>I have used it more often than LOCALS|.  However, most of the time I
>still use { ... } for now, because {: ... :} is still recently
>introduced, and more of the systems I use have { ... } than {: ... :}.
>In the next few years that should change, as systems should pick up {:
>... :}, including some that don't have { ... }.

How complicated is the {: :} mechanism?

Would a prelude like
    : { POSTPONE {: ; IMMEDIATE
    : } POSTPONE :} ; IMMEDIATE
work, to have old programs compile under a 200x standard Forth?

>- anton

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]

#37334

on 17/03/2015 16:24:31,  wrote:
> In article <2015Mar17.151849@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>"HAA" <someone@microsoft.com> writes:
>>>The proof a Standard is whether anyone is using it.  Do you use {: ... :} ?
>>
>>I have used it more often than LOCALS|.  However, most of the time I
>>still use { ... } for now, because {: ... :} is still recently
>>introduced, and more of the systems I use have { ... } than {: ... :}.
>>In the next few years that should change, as systems should pick up {:
>>... :}, including some that don't have { ... }.
> 
> How complicated is the {: :} mechanism?

In Win32Forth and my forth, they're the same.

> 
> Would a prelude like
> : { POSTPONE {: ; IMMEDIATE
> : } POSTPONE :} ; IMMEDIATE
> work, to have old programs compile under a 200x standard Forth?

There probably isn't a :} word to postpone. { {: and LOCALS| are normally
handled by parsing, so {: } would work, but {: :} would not parse
correctly.

> 
>>- anton
> 
> Groetjes Albert

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

#37394

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>How complicated is the {: :} mechanism?
>
>Would a prelude like
>    : { POSTPONE {: ; IMMEDIATE
>    : } POSTPONE :} ; IMMEDIATE
>work, to have old programs compile under a 200x standard Forth?

}/:} may not be words, or they may be words in a special wordlist, so
no, this is unlikely to work.

You find an implementations in terms of (LOCAL) in

http://www.forth200x.org/reference-implementations/locals.fs

Looking at the code, it's not very complicated.

- 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 2014: http://www.euroforth.org/ef14/

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

#37344

Anton Ertl wrote:

> "HAA" <someone@microsoft.com> writes:
>>The proof a Standard is whether anyone is using it.  Do you use {: ... :}
>>?
> 
> I have used it more often than LOCALS|.  However, most of the time I
> still use { ... } for now, because {: ... :} is still recently
> introduced, and more of the systems I use have { ... } than {: ... :}.
> In the next few years that should change, as systems should pick up {:
> ... :}, including some that don't have { ... }.

I'm not sure why I should change to {: :}.  The systems I'm using all 
support { }, and quite likely won't change that.  IMHO this was not the best 
decision to change a word that is already in pretty common practice.

I think it's fair and a good idea to define *new* features with names that 
don't conflict with existing systems, but { } is not a new feature.  It is 
older than ANS Forth.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#37396

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> "HAA" <someone@microsoft.com> writes:
>>>The proof a Standard is whether anyone is using it.  Do you use {: ... :}
>>>?
>> 
>> I have used it more often than LOCALS|.  However, most of the time I
>> still use { ... } for now, because {: ... :} is still recently
>> introduced, and more of the systems I use have { ... } than {: ... :}.
>> In the next few years that should change, as systems should pick up {:
>> ... :}, including some that don't have { ... }.
>
>I'm not sure why I should change to {: :}.  The systems I'm using all 
>support { }, and quite likely won't change that.

In that case, no need to change.  I use SwiftForth for portability
testing, and it does not support { for locals, so I will be using {:
in the long run.

>I think it's fair and a good idea to define *new* features with names that 
>don't conflict with existing systems, but { } is not a new feature.  It is 
>older than ANS Forth.

It's also a good idea for old stuff if there are naming conflicts.
E.g., there is a PARSE-WORD described (but not standardized) in
Forth-94, so that usage is obviously at least as old, but another word
with that name is also in wide use.  So we decided to standardize the
word with the name PARSE-NAME, for which no conflicts are known.

Or take the classic example of NOT, 0=, and INVERT.  This example also
shows that the old, divergent usage may never die out, so we may never
be able to ever standardize a word called NOT.

- 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 2014: http://www.euroforth.org/ef14/

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

#37291

grobibi <tristanhennequin@free.fr> writes:
>Is there a way to bypass this because, for me, a local variable has to 
>behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It 
>will initialize lst to nil (but it can be initialized to anything.).

In Gforth:

: foo { x -- ? }
  0 { lst } ... ;

- 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 2014: http://www.euroforth.org/ef14/

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

#37297

On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
> grobibi <tristanhennequin@free.fr> writes:
> >Is there a way to bypass this because, for me, a local variable has to 
> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It 
> >will initialize lst to nil (but it can be initialized to anything.).
> 
> In Gforth:
> 
> : foo { x -- ? }
>   0 { lst } ... ;

Your code fails under VFX:

: foo { x -- ? } 0 { 1st } x . 1st . ; 
Err# -421 Multiple local definitions in one word
 -> : foo { x -- ? } 0 { 1st } x . 1st . ;

It should fail, because this is a violation of ANS-Forth. See the infamous section 13.3.3:

Immediate words in a program may use (LOCAL) to implement syntaxes for local declarations with the following restrictions:
- A program shall not compile any executable code into the current definition between the time (LOCAL) is executed to identify the first local for that definition and the time of sending the single required "last local" message;

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

#37306

on 16/03/2015 17:09:36,  wrote:
> On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
>> grobibi <tristanhennequin@free.fr> writes:
>> >Is there a way to bypass this because, for me, a local variable has to
>> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
>> >will initialize lst to nil (but it can be initialized to anything.).
>>
>> In Gforth:
>>
>> : foo { x -- ? }
>>   0 { lst } ... ;
> 
> Your code fails under VFX:
> 
>: foo { x -- ? } 0 { 1st } x . 1st . ;
> Err# -421 Multiple local definitions in one word
> -> : foo { x -- ? } 0 { 1st } x . 1st . ;
> 
> It should fail, because this is a violation of ANS-Forth. See the
> infamous section 13.3.3:
> 
> Immediate words in a program may use (LOCAL) to implement syntaxes for
> local declarations with the following restrictions: - A program shall
> not compile any executable code into the current definition between
> the time (LOCAL) is executed to identify the first local for that
> definition and the time of sending the single required "last local"
> message;
> 

It doesn't fail because of that section; you're misreading, and Anton
specifically said "In Gforth". It fails on 

13.6.2.2550 ...
The following ambiguous conditions exist when:
..
– {: . . . :} is used more than once in a word.

This works in both Gforth and VFX.

: foo ( x -- ? ) 0 { x lst } ... ;

Replace { } with {: :} for modern notation.

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

#37318

On Mon, 16 Mar 2015 16:24:46 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 16/03/2015 17:09:36,  wrote:
>> On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:

>>> grobibi <tristanhennequin@free.fr> writes:
>>> >Is there a way to bypass this because, for me, a local variable has to
>>> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
>>> >will initialize lst to nil (but it can be initialized to anything.).
>>>
>>> In Gforth:
>>>
>>> : foo { x -- ? }
>>>   0 { lst } ... ;
>>
>> Your code fails under VFX:
>>
>> : foo { x -- ? } 0 { 1st } x . 1st . ;
>> Err# -421 Multiple local definitions in one word
>> -> : foo { x -- ? } 0 { 1st } x . 1st . ;
>>
>> It should fail, because this is a violation of ANS-Forth. See the
>> infamous section 13.3.3:
>>
>> Immediate words in a program may use (LOCAL) to implement syntaxes for
>> local declarations with the following restrictions: - A program shall
>> not compile any executable code into the current definition between
>> the time (LOCAL) is executed to identify the first local for that
>> definition and the time of sending the single required "last local"
>> message;
>>
>
> It doesn't fail because of that section; you're misreading, and Anton
> specifically said "In Gforth". It fails on
>
> 13.6.2.2550 ...
> The following ambiguous conditions exist when:
> ..
> – {: . . . :} is used more than once in a word.
>
> This works in both Gforth and VFX.
>
> : foo ( x -- ? ) 0 { x lst } ... ;
>
> Replace { } with {: :} for modern notation.

Well, I'm definately not up to date on locals, but I think
you posted something very different from what Anton posted.

You unconsciously fixed Anton's typing mistake, but Hugh didn't.
You changed the first set of curly braces to parenthesis, but
Hugh accepted them as-is, as what Anton meant.  So, Anton posted
two sets of locals.  It seems clear the first set is a typing
mistake and should actually be a set of parameters using
parenthesis.  I.e., just how do you use two dashes and a
quotation mark as locals?  ...  Well, Hugh showed how, and
showed that it doesn't work.

So, it seems that it was you who misread, yet again ...

Of course, we'll probably never get a correction from
Anton, as is normal when he makes a mistake.


Rod Pemberton

-- 
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

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

#37327

on 16/03/2015 23:00:05, "Rod Pemberton" wrote:
> On Mon, 16 Mar 2015 16:24:46 -0400, Alex McDonald <blog@rivadpm.com>
> wro te:
>> on 16/03/2015 17:09:36,  wrote:
>>> On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
> 
>>>> grobibi <tristanhennequin@free.fr> writes:
>>>> >Is there a way to bypass this because, for me, a local variable has
> to
>>>> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... I
> t
>>>> >will initialize lst to nil (but it can be initialized to anything.)
> .
>>>>
>>>> In Gforth:
>>>>
>>>> : foo { x -- ? }
>>>>   0 { lst } ... ;
>>>
>>> Your code fails under VFX:
>>>
>>> : foo { x -- ? } 0 { 1st } x . 1st . ;
>>> Err# -421 Multiple local definitions in one word
>>> -> : foo { x -- ? } 0 { 1st } x . 1st . ;
>>>
>>> It should fail, because this is a violation of ANS-Forth. See the
>>> infamous section 13.3.3:
>>>
>>> Immediate words in a program may use (LOCAL) to implement syntaxes fo
> r
>>> local declarations with the following restrictions: - A program shall
> 
>>> not compile any executable code into the current definition between
>>> the time (LOCAL) is executed to identify the first local for that
>>> definition and the time of sending the single required "last local"
>>> message;
>>>
>>
>> It doesn't fail because of that section; you're misreading, and Anton
>> specifically said "In Gforth". It fails on
>>
>> 13.6.2.2550 ...
>> The following ambiguous conditions exist when:
>> ..
>> – {: . . . :} is used more than once in a word.
>>
>> This works in both Gforth and VFX.
>>
>> : foo ( x -- ? ) 0 { x lst } ... ;
>>
>> Replace { } with {: :} for modern notation.
> 
> Well, I'm definately not up to date on locals, but I think
> you posted something very different from what Anton posted.

It's so different that it's identical.

> 
> You unconsciously fixed Anton's typing mistake, but Hugh didn't.

Anton was quite clear that his code was for Gforth. Gforth supports
multiple declarations of locals, so I wasn't as unconscious as you
assume.

> You changed the first set of curly braces to parenthesis, but
> Hugh accepted them as-is, as what Anton meant.  So, Anton posted
> two sets of locals.  It seems clear the first set is a typing
> mistake and should actually be a set of parameters using
> parenthesis.  I.e., just how do you use two dashes and a
> quotation mark as locals?  ...  Well, Hugh showed how, and
> showed that it doesn't work.
> 

In Gforth (again!) the locals list can be represented in a
stack-diagram-like way. The double dash -- starts a comment inside the
locals declaration; anything between it and the closing brace } is
ignored.

http://www.public.iastate.edu/~forth/gforth_31.html

There are other Forths that support this format; Win32Forth for example.

> So, it seems that it was you who misread, yet again ...
> 
> Of course, we'll probably never get a correction from
> Anton, as is normal when he makes a mistake.
> 
> 

Perhaps he has you both killfiled.

> Rod Pemberton
> 

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

#37332

On Tue, 17 Mar 2015 12:06:34 GMT, "Alex McDonald" <blog@rivadpm.com>
wrote:

>In Gforth (again!) the locals list can be represented in a
>stack-diagram-like way. The double dash -- starts a comment inside the
>locals declaration; anything between it and the closing brace } is
>ignored.

{: in1 in2 | loc1 ... locn -- o1 o2 :}

The stack diagram layout is deliberate and sometimes important. It
allows the programmer to define a full stack comment. Although what
is between '--' and ':}' is technically a comment, it is mostly a
formal notation for the output data. Not using the notation this way
is bad practice IMHO.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

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

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

csiph-web