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

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

RfD: Quotations

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

Contents

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

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

#40934

On 30/07/2015 02:51, Elizabeth D. Rather wrote:
> It's appropriate for a standard to avoid standardizing any name in a way
> that conflicts with widespread usage, regardless of whether the usage is
> of a commercial on non-comercial system.

Widespread usage and common practice was writing { ... } for locals.

Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even" 
widespread" at all!

Multi-line comments were commonly implemeted by COMMENT, or "((" and a 
bunch of other idioms.

The allusion to commercialism was because I'm uncomfortable with a 
standard being influenced by commercial minority interests instead of 
the wish to formalize widespread established developments in the 
language usage.
And this is just what happend.

--
Regards,
Bernd Linsel

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

#40938

On Wednesday, July 29, 2015 at 6:31:00 PM UTC-7, Bernd Linsel wrote:
> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
> > It's appropriate for a standard to avoid standardizing any name in a way
> > that conflicts with widespread usage, regardless of whether the usage is
> > of a commercial on non-comercial system.
> 
> Widespread usage and common practice was writing { ... } for locals.
> 
> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even" 
> widespread" at all!
> 
> Multi-line comments were commonly implemeted by COMMENT, or "((" and a 
> bunch of other idioms.
> 
> The allusion to commercialism was because I'm uncomfortable with a 
> standard being influenced by commercial minority interests instead of 
> the wish to formalize widespread established developments in the 
> language usage.
> And this is just what happend.
> 
> --
> Regards,
> Bernd Linsel

What Bernd Linsel is saying here is true.

I have COMMENT in my novice-package. It has the advantage that any delimiter can be used --- Forth Inc. should have just adopted my COMMENT and gotten an improvement over their { plus have avoided clashing with 20+ years worth of legacy code that uses { for defining local-variables --- it was just arrogance that impelled them to demand that everybody in the Forth community conform to SwiftForth, and to say that SwiftForth can't change in any way.

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

#40939

joi, 30 iulie 2015, 05:30:07 UTC+3, hughag...@gmail.com a scris:
> On Wednesday, July 29, 2015 at 6:31:00 PM UTC-7, Bernd Linsel wrote:
> > On 30/07/2015 02:51, Elizabeth D. Rather wrote:
> > > It's appropriate for a standard to avoid standardizing any name in a way
> > > that conflicts with widespread usage, regardless of whether the usage is
> > > of a commercial on non-comercial system.
> > 
> > Widespread usage and common practice was writing { ... } for locals.
> > 
> > Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even" 
> > widespread" at all!
> > 
> > Multi-line comments were commonly implemeted by COMMENT, or "((" and a 
> > bunch of other idioms.
> > 
> > The allusion to commercialism was because I'm uncomfortable with a 
> > standard being influenced by commercial minority interests instead of 
> > the wish to formalize widespread established developments in the 
> > language usage.
> > And this is just what happend.
> > 
> > --
> > Regards,
> > Bernd Linsel
> 
> What Bernd Linsel is saying here is true.
> 
> I have COMMENT in my novice-package. It has the advantage that any delimiter can be used --- Forth Inc. should have just adopted my COMMENT and gotten an improvement over their { plus have avoided clashing with 20+ years worth of legacy code that uses { for defining local-variables --- it was just arrogance that impelled them to demand that everybody in the Forth community conform to SwiftForth, and to say that SwiftForth can't change in any way.

I agree too. Besides, it is so uninspired to use such good symbols { } for what? comments?!

I also have COMMENT. In my system the commenting functionality is very flexible
(I have support directly in the kernel). For some time I used "comment &"
but then I got tired and I defined &&& being "comment &".
Seems that the & symbol is quite ugly and not being used so much in forth.

For commenting multiple lines of code I use:
&&&
...
...
...
\ &
This is a known trick. It lets you commenting/uncommenting
the whole piece of code just with one '\' in front of &&&:
\ &&&
code
code
code
\ &

Anyway, I still have COMMENT which lets you use any terminator character.

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

#40940

BTW, my working version of the man or boy is this:

defer aa
:  0   0 ;
:  1   1 ;
: -1  -1 ;
: a { k x1 x2 x3 x4 x5 | b -- n }
  [ k @ 1- k !
    k @ b @ x1 @ x2 @ x3 @ x4 @ aa
  ] b !
  k @ 0<= if
    x4 @ execute x5 @ execute +
  else
    b @ execute
  then ;
' a is aa
3 ' 1 ' -1 ' -1 ' 1 ' 0 a . cr

Works only to 3, 4 is too much already.
I had to change the first "constants". In my system CONSTANT doesn't create
code but a "data" dictionary entry.

I still don't know what is the point of this "man or boy". It's working
(except it requires BIG stacks - and I have no interest in that a system)

The simple conclusion is that locals are simple to use inside quotations.
The rule that a quotation using a parent local will go wild if parent exited (common sense - the parent local frame is no longer valid) can be simply
teached, there is no need to define "undefined behaviour" or "ambiguous
conditions".

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

#40963

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>I still don't know what is the point of this "man or boy".

The point is to test whether a compiler implements access to outer
locals correctly (i.e., statically scoped), even in the presence of
multiple activation records for the outer locals, and different
accesses referring to different actication records.

>The simple conclusion is that locals are simple to use inside quotations.
>The rule that a quotation using a parent local will go wild if parent exited (common sense - the parent local frame is no longer valid) can be simply
>teached, there is no need to define "undefined behaviour" or "ambiguous
>conditions".

For the present proposal there is no need for an ambiguous condition.
The proposal could just declare references to an outer local to be an
error, and the compiler would be required to report the error.  Of
course, this would close the door to allowing outer locals, at least
with the [: ... ;] syntax.  Do you want this?

For a proposal that allowed access to outer locals as long as the
definition in which they were defined has not been left would pretty
much be guaranteed to specify an ambiguous condition.  We don't want
to require the effort in the compiler or run-time system that would be
necessary to catch a breach of that limitation, so we would define a
breach of that limitation to be an ambiguous condition.

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

#40975

> For the present proposal there is no need for an ambiguous condition.
> The proposal could just declare references to an outer local to be an
> error, and the compiler would be required to report the error.  Of
> course, this would close the door to allowing outer locals, at least
> with the [: ... ;] syntax.  Do you want this?
> 
Yes. Better than having another ambiguous condition in the standard.
The question is: do you want an ambiguous condition?

> For a proposal that allowed access to outer locals as long as the
> definition in which they were defined has not been left would pretty
> much be guaranteed to specify an ambiguous condition.  We don't want
> to require the effort in the compiler or run-time system that would be
> necessary to catch a breach of that limitation, so we would define a
> breach of that limitation to be an ambiguous condition.
> 
What about C standard? You are allowed to get the address of a local 
variable. You can use it after the local is gone out of scope. It happened
to me a few times. Of course, the program crashed. 
What is the C standard saying about this?
The Forth standard can say the same thing. And BTW, I have access to my
locals address (they are used with @ and ! like normal variables). It's the
same problem, using a local after it is gone out of scope.

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

#41010

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> For the present proposal there is no need for an ambiguous condition.
>> The proposal could just declare references to an outer local to be an
>> error, and the compiler would be required to report the error.  Of
>> course, this would close the door to allowing outer locals, at least
>> with the [: ... ;] syntax.  Do you want this?
>> 
>Yes. Better than having another ambiguous condition in the standard.
>The question is: do you want an ambiguous condition?

The benefits in this case are:

1) Systems that want to support access to outer locals don't need a
   separate syntax for that.

2) If we find consensus on what to do about outer locals, we can
   extend the standard to include that, without breaking existing
   standard programs.

   However, most likely we won't find consensus: there will likely be
   some who say that it is not needed, and among the rest there will
   probably be different approaches, too.  And even if there is a
   consensus on how to do it, there will probably be existing code
   (due to benefit 1) for some existing system that would conflict
   with the consensus, and therefore we would need a new name anyway.
   
   It might be easier to extend the standard in this direction if we
   just specify that outer locals are not visible (thus eliminating
   benefit 1): While extending the standard would break programs such
   as

   variable x : foo {: x :} [: x @ . :] execute ;

   there will be few, if any, such programs.

So maybe we should not make it ambiguous after all.  Systems
experimenting with access to outer locals should use a different
syntax for that.

>What about C standard? You are allowed to get the address of a local 
>variable. You can use it after the local is gone out of scope. It happened
>to me a few times. Of course, the program crashed. 
>What is the C standard saying about this?

|6.2.4 Storage durations of objects
[...]
|If an object is referred to outside of its lifetime, the behavior is
|undefined.

>The Forth standard can say the same thing.

And how is undefined behavior better than an ambiguous condition?

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

#41012

on 31/07/2015 11:54:31,  wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>> For the present proposal there is no need for an ambiguous condition.
>>> The proposal could just declare references to an outer local to be an
>>> error, and the compiler would be required to report the error.  Of
>>> course, this would close the door to allowing outer locals, at least
>>> with the [: ... ;] syntax.  Do you want this?
>>>
>>Yes. Better than having another ambiguous condition in the standard.
>>The question is: do you want an ambiguous condition?
> 
> The benefits in this case are:
> 
> 1) Systems that want to support access to outer locals don't need a
> separate syntax for that.
> 
> 2) If we find consensus on what to do about outer locals, we can
> extend the standard to include that, without breaking existing
> standard programs.
> 
> However, most likely we won't find consensus: there will likely be
> some who say that it is not needed, and among the rest there will
> probably be different approaches, too.  And even if there is a
> consensus on how to do it, there will probably be existing code
> (due to benefit 1) for some existing system that would conflict
> with the consensus, and therefore we would need a new name anyway.
> 
> It might be easier to extend the standard in this direction if we
> just specify that outer locals are not visible (thus eliminating
> benefit 1): While extending the standard would break programs such
> as
> 
> variable x : foo {: x :} [: x @ . :] execute ;
> 
> there will be few, if any, such programs.
> 
> So maybe we should not make it ambiguous after all.  Systems
> experimenting with access to outer locals should use a different
> syntax for that.
> 
>>What about C standard? You are allowed to get the address of a local
>>variable. You can use it after the local is gone out of scope. It happened
>>to me a few times. Of course, the program crashed.
>>What is the C standard saying about this?
> 
>|6.2.4 Storage durations of objects
> [...]
>|If an object is referred to outside of its lifetime, the behavior is
>|undefined.
> 
>>The Forth standard can say the same thing.
> 
> And how is undefined behavior better than an ambiguous condition?
> 
> - anton

While I'm in rant mood, let me trash the idea that "undefined behaviour"
actually means something in terms of the RfD; it doesn't.

I have a system that, when you do this;

: foo { a } [: a 1+ . ;] execute ;
1 foo

has a specified behaviour. It adds 1 to the number you give it and prints
the string representing that number. This is *not* undefined behaviour.
It is defined by the implementation of my compiler, and allowed by the
specification. It actually has a reasonable interpretation.

When fed the above code, another compiler might document the outcome as
printing the string "Hugh Aguilar says fake" and then chopping the door
down to your office and setting fire to you and the contents. It would
still be compliant.

The C spec that refers to prodding dead objects says "Don't do that.
Never. Ever.". The RfD specification doesn't presume to tell you not to
do that. It says this is an "ambiguous condition: a circumstance for
which this standard does not prescribe a specific behavior".

End of rant.

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

#41014

vineri, 31 iulie 2015, 14:48:34 UTC+3, Alex McDonald a scris:
> on 31/07/2015 11:54:31,  wrote:
> > Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >>> For the present proposal there is no need for an ambiguous condition.
> >>> The proposal could just declare references to an outer local to be an
> >>> error, and the compiler would be required to report the error.  Of
> >>> course, this would close the door to allowing outer locals, at least
> >>> with the [: ... ;] syntax.  Do you want this?
> >>>
> >>Yes. Better than having another ambiguous condition in the standard.
> >>The question is: do you want an ambiguous condition?
> > 
> > The benefits in this case are:
> > 
> > 1) Systems that want to support access to outer locals don't need a
> > separate syntax for that.
> > 
> > 2) If we find consensus on what to do about outer locals, we can
> > extend the standard to include that, without breaking existing
> > standard programs.
> > 
> > However, most likely we won't find consensus: there will likely be
> > some who say that it is not needed, and among the rest there will
> > probably be different approaches, too.  And even if there is a
> > consensus on how to do it, there will probably be existing code
> > (due to benefit 1) for some existing system that would conflict
> > with the consensus, and therefore we would need a new name anyway.
> > 
> > It might be easier to extend the standard in this direction if we
> > just specify that outer locals are not visible (thus eliminating
> > benefit 1): While extending the standard would break programs such
> > as
> > 
> > variable x : foo {: x :} [: x @ . :] execute ;
> > 
> > there will be few, if any, such programs.
> > 
> > So maybe we should not make it ambiguous after all.  Systems
> > experimenting with access to outer locals should use a different
> > syntax for that.
> > 
> >>What about C standard? You are allowed to get the address of a local
> >>variable. You can use it after the local is gone out of scope. It happened
> >>to me a few times. Of course, the program crashed.
> >>What is the C standard saying about this?
> > 
> >|6.2.4 Storage durations of objects
> > [...]
> >|If an object is referred to outside of its lifetime, the behavior is
> >|undefined.
> > 
> >>The Forth standard can say the same thing.
> > 
> > And how is undefined behavior better than an ambiguous condition?
> > 
> > - anton
> 
> While I'm in rant mood, let me trash the idea that "undefined behaviour"
> actually means something in terms of the RfD; it doesn't.
> 
> I have a system that, when you do this;
> 
> : foo { a } [: a 1+ . ;] execute ;
> 1 foo
> 
> has a specified behaviour. It adds 1 to the number you give it and prints
> the string representing that number. This is *not* undefined behaviour.
> It is defined by the implementation of my compiler, and allowed by the
> specification. It actually has a reasonable interpretation.
> 
> When fed the above code, another compiler might document the outcome as
> printing the string "Hugh Aguilar says fake" and then chopping the door
> down to your office and setting fire to you and the contents. It would
> still be compliant.
> 
> The C spec that refers to prodding dead objects says "Don't do that.
> Never. Ever.". The RfD specification doesn't presume to tell you not to
> do that. It says this is an "ambiguous condition: a circumstance for
> which this standard does not prescribe a specific behavior".
> 
> End of rant.

: foo { a } [: a 1+ . ;] execute ;
1 foo

Defined behaviour.

: foo { a } [: a 1+ . ;] ;
1 foo execute

Undefined behaviour. Ambiguous condition if you like.

Where is the problem? In the "visibility" of the outer locals or the
overall usage? The ambiguous condition arise when accesing a local
variable out of its scope, not in the possibility itself of accesing of an 
outer local variable at all.

Don't act that you don't understand this simple thing.

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

#41015

on 31/07/2015 13:40:30, Raimond Dragomir wrote:


> 
> Where is the problem? In the "visibility" of the outer locals or the
> overall usage? The ambiguous condition arise when accesing a local
> variable out of its scope, not in the possibility itself of accesing
> of an outer local variable at all.
> 
> Don't act that you don't understand this simple thing.
> 

For clarity, the RfD states:

(non-normative)
Locals: A quotation may not be able to access the locals of the outer
word because it has no knowledge of when it might be executed and hence
whether outer locals are still alive. It does permit defining and
accessing its own locals.

(normative)
It is an ambiguous condition if outer locals are visible and referred to
in the nested definition.

There appears to be rough consensus on having [: with the same privileges
as words defined with : and :NONAME. That means they are mandated to have
their own locals; we appear agreed on that.

There's nothing new here about simple visibility of locals; take DOES> as
an example. This:

: a { val1 val2 } create val1 , val2 , does> 2@ { val1 x } val1 x + . ;

The first local VAL1 is a different local from the post-DOES> VAL1, and
VAL2 is not visible in the DOES> section. No-one has suggested changing
this behaviour to support a closure over DOES>.

There are already a number of other restrictions on the use of locals
that some implementations relax. The RfD permits referring to outer
locals (and permits closures too should you wish to implement them). It
doesn't force implementations to support anything except the simplest
case. I would be reluctant to see a requirement to support

: foo { A } [: { B } A B [: { a } a b ;] B ;] A ... ;

which is what you are proposing.

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

#41016

on 31/07/2015 14:46:53, "Alex McDonald" wrote:
>: foo { A } [: { B } A B [: { a } a b ;] B ;] A ... ;

Oops, correction:

: foo { A } [: { B } A B [: { a } a B ;] B ;] A ... ;

The case is meant to indicate scope and visibility.

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

#41019

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>: foo { a } [: a 1+ . ;] execute ;
>1 foo
>
>Defined behaviour.
>
>: foo { a } [: a 1+ . ;] ;
>1 foo execute
>
>Undefined behaviour. Ambiguous condition if you like.
>
>Where is the problem?

Even the first case has an implementation cost.  It is unclear if the
benefit is worth that cost.

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

#41025

On Friday, July 31, 2015 at 4:19:44 AM UTC-7, Anton Ertl wrote:
>    It might be easier to extend the standard in this direction if we
>    just specify that outer locals are not visible (thus eliminating
>    benefit 1): While extending the standard would break programs such
>    as
> 
>    variable x : foo {: x :} [: x @ . :] execute ;
> 
>    there will be few, if any, such programs.
> 
> So maybe we should not make it ambiguous after all.  Systems
> experimenting with access to outer locals should use a different
> syntax for that.

Do you really not understand the concept of general-purpose data-structures???

The best explanation for your apparent failure to understand general-purpose data-structures is that you have accepted that Forth Inc. will never allow anything except Payson-faked quotations, so you play dumb to get a along. You relegate real quotations to "systems experimenting with access to outer locals" which is just another term for "non-standard" --- meaning that Forth-200x won't support general-purpose data-structures --- meaning that the Forth community is stuck with Elizabeth Rather stupidity:

"Does '*every* application' you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your 'general-purpose' structure."

As you may remember, I left Forth-200x because I was offended by Elizabeth Rather saying this about my novice-package. I won't tolerate such relentless stupidity --- I don't think anybody will tolerate such stupidity, which is why Forth-200x will be ignored by the whole world --- by standardizing Payson-faked quotations you are making the entire Forth community look stupid, including Forthers such as myself who are innocent because we have abandoned Forth-200x.

I think that you are a coward because you are willing to tell lies in order to keep your job as chairperson of the Forth-200x committee. Elizabeth Rather tells you that general-purpose data-structures are impossible, so you say that they are impossible. Be a man and admit that general-purpose data-structures are possible! You will lose your job the next day (most likely Alex McDonald will be given your job as a reward for his loyalty) --- but at least you will have been a man for one day.

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

#41028

on 31/07/2015 21:16:16,  wrote:
> As you may remember, I left Forth-200x because I was offended by
> Elizabeth Rather saying this about my novice-package.

No, you asked to be kicked out of the Forth 200x group. The group agreed
that you should go.


https://groups.yahoo.com/neo/groups/forth200x/conversations/messages/1105

Even back then, you were misunderstanding quotations, nested functions
and closures.


https://groups.yahoo.com/neo/groups/forth200x/conversations/messages/1063
https://groups.yahoo.com/neo/groups/forth200x/conversations/messages/1064
https://groups.yahoo.com/neo/groups/forth200x/conversations/messages/1065

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

#40944

On Wednesday, July 29, 2015 at 9:19:09 PM UTC-7, Raimond Dragomir wrote:
> joi, 30 iulie 2015, 05:30:07 UTC+3, hughag...@gmail.com a scris:
> > On Wednesday, July 29, 2015 at 6:31:00 PM UTC-7, Bernd Linsel wrote:
> > > On 30/07/2015 02:51, Elizabeth D. Rather wrote:
> > > > It's appropriate for a standard to avoid standardizing any name in a way
> > > > that conflicts with widespread usage, regardless of whether the usage is
> > > > of a commercial on non-comercial system.
> > > 
> > > Widespread usage and common practice was writing { ... } for locals.
> > > 
> > > Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even" 
> > > widespread" at all!
> > > 
> > > Multi-line comments were commonly implemeted by COMMENT, or "((" and a 
> > > bunch of other idioms.
> > > 
> > > The allusion to commercialism was because I'm uncomfortable with a 
> > > standard being influenced by commercial minority interests instead of 
> > > the wish to formalize widespread established developments in the 
> > > language usage.
> > > And this is just what happend.
> > > 
> > > --
> > > Regards,
> > > Bernd Linsel
> > 
> > What Bernd Linsel is saying here is true.
> > 
> > I have COMMENT in my novice-package. It has the advantage that any delimiter can be used --- Forth Inc. should have just adopted my COMMENT and gotten an improvement over their { plus have avoided clashing with 20+ years worth of legacy code that uses { for defining local-variables --- it was just arrogance that impelled them to demand that everybody in the Forth community conform to SwiftForth, and to say that SwiftForth can't change in any way.
> 
> I agree too. Besides, it is so uninspired to use such good symbols { } for what? comments?!
> 
> I also have COMMENT. In my system the commenting functionality is very flexible
> (I have support directly in the kernel). For some time I used "comment &"
> but then I got tired and I defined &&& being "comment &".
> Seems that the & symbol is quite ugly and not being used so much in forth.
> 
> For commenting multiple lines of code I use:
> &&&
> ...
> ...
> ...
> \ &
> This is a known trick. It lets you commenting/uncommenting
> the whole piece of code just with one '\' in front of &&&:
> \ &&&
> code
> code
> code
> \ &
> 
> Anyway, I still have COMMENT which lets you use any terminator character.

That is a good trick. What I did instead though, is define & like this:

: & ( -- )
    cr ." warning: we are using the code that had been commented out previously" ;


This is useful because it reminds the programmer that the code is in use, in case he has forgotten, so he doesn't get confused as to what code is in use and what has been commented out.

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

#40970

On 7/29/15 11:19 PM, Raimond Dragomir wrote:
> joi, 30 iulie 2015, 05:30:07 UTC+3, hughag...@gmail.com a scris:
>> On Wednesday, July 29, 2015 at 6:31:00 PM UTC-7, Bernd Linsel wrote:
>>> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
>>>> It's appropriate for a standard to avoid standardizing any name in a way
>>>> that conflicts with widespread usage, regardless of whether the usage is
>>>> of a commercial on non-comercial system.
>>>
>>> Widespread usage and common practice was writing { ... } for locals.
>>>
>>> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even"
>>> widespread" at all!

It had been in use since the 1970's, with literally thousands of systems 
and running applications in the field.

>>> Multi-line comments were commonly implemeted by COMMENT, or "((" and a
>>> bunch of other idioms.

I do not believe we were the only ones to use { ... }. As you say, there 
were a bunch of idioms in use.

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]

#40941

joi, 30 iulie 2015, 04:31:00 UTC+3, Bernd Linsel a scris:
> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
> > It's appropriate for a standard to avoid standardizing any name in a way
> > that conflicts with widespread usage, regardless of whether the usage is
> > of a commercial on non-comercial system.
> 
> Widespread usage and common practice was writing { ... } for locals.
> 
> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even" 
> widespread" at all!
> 
> Multi-line comments were commonly implemeted by COMMENT, or "((" and a 
> bunch of other idioms.
> 
> The allusion to commercialism was because I'm uncomfortable with a 
> standard being influenced by commercial minority interests instead of 
> the wish to formalize widespread established developments in the 
> language usage.
> And this is just what happend.
> 
> --
> Regards,
> Bernd Linsel

I would add this: No one followed the  SwiftForth practice of { } comments.
I didn't see another system to have these comments.

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

#40951

on 30/07/2015 02:31:03, Bernd Linsel wrote:
> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
>> It's appropriate for a standard to avoid standardizing any name in a way
>> that conflicts with widespread usage, regardless of whether the usage is
>> of a commercial on non-comercial system.
> 
> Widespread usage and common practice was writing { ... } for locals.
> 
> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even"
> widespread" at all!
> 
> Multi-line comments were commonly implemeted by COMMENT, or "((" and a
> bunch of other idioms.
> 
> The allusion to commercialism was because I'm uncomfortable with a
> standard being influenced by commercial minority interests instead of
> the wish to formalize widespread established developments in the
> language usage.
> And this is just what happend.

For the present RfD, I take it that you are comfortable with its proposed
syntax and semantics?

> 
> --
> Regards,
> Bernd Linsel
> 

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

#40952

Am 30.07.2015 um 11:01 schrieb Alex McDonald:
> on 30/07/2015 02:31:03, Bernd Linsel wrote:
>> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
>>> It's appropriate for a standard to avoid standardizing any name in a way
>>> that conflicts with widespread usage, regardless of whether the usage is
>>> of a commercial on non-comercial system.
>>
>> Widespread usage and common practice was writing { ... } for locals.
>>
>> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even"
>> widespread" at all!
>>
>> Multi-line comments were commonly implemeted by COMMENT, or "((" and a
>> bunch of other idioms.
>>
>> The allusion to commercialism was because I'm uncomfortable with a
>> standard being influenced by commercial minority interests instead of
>> the wish to formalize widespread established developments in the
>> language usage.
>> And this is just what happend.
>
> For the present RfD, I take it that you are comfortable with its proposed
> syntax and semantics?

My opinion 'bout syntax and semantics is irrelevant.
Fortunately Forth is so flexible, one can redefine anything after one's 
fancy.
Besides... syntax in Forth?? O_O

I'm just annoyed by the constantly repeated but unfounded assertion that 
{ ... } had been common practice for comments, not locals, so that the 
F200x committee had to find another idiom and ended up with {: ... :}

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

#40954

on 30/07/2015 11:00:40, Bernd Linsel wrote:
> Am 30.07.2015 um 11:01 schrieb Alex McDonald:
>> on 30/07/2015 02:31:03, Bernd Linsel wrote:
>>> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
>>>> It's appropriate for a standard to avoid standardizing any name in a way
>>>> that conflicts with widespread usage, regardless of whether the usage is
>>>> of a commercial on non-comercial system.
>>>
>>> Widespread usage and common practice was writing { ... } for locals.
>>>
>>> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even"
>>> widespread" at all!
>>>
>>> Multi-line comments were commonly implemeted by COMMENT, or "((" and a
>>> bunch of other idioms.
>>>
>>> The allusion to commercialism was because I'm uncomfortable with a
>>> standard being influenced by commercial minority interests instead of
>>> the wish to formalize widespread established developments in the
>>> language usage.
>>> And this is just what happend.
>>
>> For the present RfD, I take it that you are comfortable with its proposed
>> syntax and semantics?
> 
> My opinion 'bout syntax and semantics is irrelevant.

OK.

> Fortunately Forth is so flexible, one can redefine anything after
> one's fancy.
> Besides... syntax in Forth?? O_O
> 
> I'm just annoyed by the constantly repeated but unfounded assertion
> that { ... } had been common practice for comments, not locals, so
> that the F200x committee had to find another idiom and ended up with
> {: ... :}
> 

Yes, I get that.

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

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

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

csiph-web