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

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

Test of COMPILE,

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

Contents

  Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 08:20 -0800
    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-26 11:36 -0600
      Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 09:44 -0800
      Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 12:14 -0800
        Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 15:08 -0800
          Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 16:03 -0800
            Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 16:12 -0800
            Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-26 17:10 -1000
              Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 19:33 -0800
                Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-26 18:28 -1000
                Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-27 14:02 +0000
                  Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-27 08:42 -0800
                Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-27 09:08 -0800
            Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-27 04:21 -0600
    Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-26 18:41 +0200
      Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 09:51 -0800
        Re: Test of COMPILE, Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-26 21:31 +0100
          Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 14:09 -0800
        Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-27 14:17 +0000
      Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 10:01 -0800
        Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-26 20:25 +0200
          Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 15:04 -0800
        Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 11:23 -0800
          Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-26 14:48 -0800
            Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 16:00 -0800
              Re: Test of COMPILE, Coos Haak <chforth@hccnet.nl> - 2011-11-27 02:09 +0100
                Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-26 18:11 -0800
                  Re: Test of COMPILE, Gerry <gerry@jackson9000.fsnet.co.uk> - 2011-11-27 00:09 -0800
                    Re: Test of COMPILE, Mark Wills <forthfreak@gmail.com> - 2011-11-27 00:47 -0800
                      Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-27 10:48 +0200
                        Re: Test of COMPILE, Mark Wills <forthfreak@gmail.com> - 2011-11-27 05:24 -0800
                    Re: Test of COMPILE, Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-11-27 21:08 +0000
                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-27 21:18 +0000
                      Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-27 16:58 -0800
                        Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-28 12:03 +0000
                    Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-27 15:00 -0800
                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-28 11:39 +0000
                        Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-28 04:52 -0800
                          Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-28 18:05 +0000
                            Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-28 12:45 -0600
                              Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-28 20:17 +0000
                                Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-28 14:22 -0800
                                  Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-29 08:08 +0000
                                Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 04:49 -0600
                                  Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-29 16:00 +0000
                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-30 10:45 -0600
                                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-01 08:58 +0000
                                  Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-12-01 09:46 -0800
                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-01 12:00 -0600
                              Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-28 12:29 -0800
                                Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 04:53 -0600
                                  Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-29 11:04 +0000
                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 05:42 -0600
                                      Re: Test of COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-29 15:46 +0000
                                        Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 09:59 -0600
                                        Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-29 08:55 -1000
                                        Re: Test of COMPILE, "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-11-30 05:58 -0500
                                          Re: Test of COMPILE, Alex McDonald <blog@rivadpm.com> - 2011-11-30 03:07 -0800
                                          Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-30 07:54 -0800
                                      Re: Test of COMPILE, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-11-29 15:50 +0000
                                        Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-29 10:01 -0600
                                        Re: Test of COMPILE, Tarkin <tarkin000@gmail.com> - 2011-11-29 13:07 -0800
                                  Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-29 17:04 -0800
                                    Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-29 15:52 -1000
                                      Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-29 21:29 -0800
                                        Re: Test of COMPILE, "Elizabeth D. Rather" <erather@forth.com> - 2011-11-29 19:52 -1000
                                          Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-30 07:49 -0800
                                            Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-30 10:19 -0600
                                              Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-11-30 12:19 -0800
                                                Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-30 14:31 -0600
                                                  Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-12-01 10:36 -0800
                                                    Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-01 13:08 -0600
                                                      Re: Test of COMPILE, BruceMcF <agila61@netscape.net> - 2011-12-01 22:04 -0800
                        Re: Test of COMPILE, Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-28 05:05 -0800
                      Re: Test of COMPILE, Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-28 06:25 -0600
                Re: Test of COMPILE, mhx@iae.nl (Marcel Hendrix) - 2011-11-27 08:01 +0200
                  Re: Test of COMPILE, Coos Haak <chforth@hccnet.nl> - 2011-11-27 14:09 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#7495 — Test of COMPILE,

I realized that the implementation of COMPILE, in kForth is broken. In
fixing the problem, I devised a few tests. However, the following test
does not seem to load in Gforth:

2 constant two  ok
: test [ ' two compile, 3 ] - 1 = ;

Gforth fails to load the definition of TEST

--
:2: unstructured
: test [ ' two compile, 3 ] - 1 = >>>;<<<
Backtrace:
$7F6A74418C28 throw
$7F6A744292E0 c(abort")
$7F6A744368B0 def?
$7F6A744224E8 ;-hook
$7F6A744205C8 execute
--

The test loads and runs properly under my patches for kForth. Is there
a problem with the definition of TEST ?

Krishna

[toc] | [next] | [standalone]

#7496

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> I realized that the implementation of COMPILE, in kForth is broken. In
> fixing the problem, I devised a few tests. However, the following test
> does not seem to load in Gforth:
> 
> 2 constant two  ok
> : test [ ' two compile, 3 ] - 1 = ;
> 
> Gforth fails to load the definition of TEST
> 
> --
> :2: unstructured
> : test [ ' two compile, 3 ] - 1 = >>>;<<<
> Backtrace:
> $7F6A74418C28 throw
> $7F6A744292E0 c(abort")
> $7F6A744368B0 def?
> $7F6A744224E8 ;-hook
> $7F6A744205C8 execute
> --
> 
> The test loads and runs properly under my patches for kForth. Is there
> a problem with the definition of TEST ?

It doesn't seem to be a standard Forth program.  What is the compiler
supposed to do with that 3 you left on the stack?

Andrew.

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

#7498

On Nov 26, 11:36 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > I realized that the implementation of COMPILE, in kForth is broken. In
> > fixing the problem, I devised a few tests. However, the following test
> > does not seem to load in Gforth:
>
> > 2 constant two  ok
> > : test [ ' two compile, 3 ] - 1 = ;
>
> > Gforth fails to load the definition of TEST
>
> > --
> > :2: unstructured
> > : test [ ' two compile, 3 ] - 1 = >>>;<<<
> > Backtrace:
> > $7F6A74418C28 throw
> > $7F6A744292E0 c(abort")
> > $7F6A744368B0 def?
> > $7F6A744224E8 ;-hook
> > $7F6A744205C8 execute
> > --
>
> > The test loads and runs properly under my patches for kForth. Is there
> > a problem with the definition of TEST ?
>
> It doesn't seem to be a standard Forth program.  What is the compiler
> supposed to do with that 3 you left on the stack?
>
> Andrew.

A stack comment helps.

: test ( n -- flag ) [ ' two compile, 3 ] - 1 = ;

The 3 should be placed on the stack when TEST is compiled, since we
are in interpretation state. Then, when we run TEST right after its
definition, it should produce a true flag on the stack.

I can't see what's non-standard about this usage.

Krishna

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

#7504

On Nov 26, 11:36 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > I realized that the implementation of COMPILE, in kForth is broken. In
> > fixing the problem, I devised a few tests. However, the following test
> > does not seem to load in Gforth:
>
> > 2 constant two  ok
> > : test [ ' two compile, 3 ] - 1 = ;
>
> > Gforth fails to load the definition of TEST
>
> > --
> > :2: unstructured
> > : test [ ' two compile, 3 ] - 1 = >>>;<<<
> > Backtrace:
> > $7F6A74418C28 throw
> > $7F6A744292E0 c(abort")
> > $7F6A744368B0 def?
> > $7F6A744224E8 ;-hook
> > $7F6A744205C8 execute
> > --
>
> > The test loads and runs properly under my patches for kForth. Is there
> > a problem with the definition of TEST ?
>
> It doesn't seem to be a standard Forth program.  What is the compiler
> supposed to do with that 3 you left on the stack?
>
> Andrew.

More fundamentally, would the following be considered non-standard? If
so, why?

--
Gforth 0.7.9-20101227, Copyright (C) 1995-2011 Free Software
Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: test [ 3 ] ;
:1: unstructured
: test [ 3 ] >>>;<<<
Backtrace:
$7FBC85886C28 throw
$7FBC858972E0 c(abort")
$7FBC858A48B0 def?
$7FBC858904E8 ;-hook
$7FBC8588E5C8 execute
--

Krishna

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

#7512

On Nov 26, 8:14 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> On Nov 26, 11:36 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>
>
>
>
>
>
>
>
>
> > Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > > I realized that the implementation of COMPILE, in kForth is broken. In
> > > fixing the problem, I devised a few tests. However, the following test
> > > does not seem to load in Gforth:
>
> > > 2 constant two  ok
> > > : test [ ' two compile, 3 ] - 1 = ;
>
> > > Gforth fails to load the definition of TEST
>
> > > --
> > > :2: unstructured
> > > : test [ ' two compile, 3 ] - 1 = >>>;<<<
> > > Backtrace:
> > > $7F6A74418C28 throw
> > > $7F6A744292E0 c(abort")
> > > $7F6A744368B0 def?
> > > $7F6A744224E8 ;-hook
> > > $7F6A744205C8 execute
> > > --
>
> > > The test loads and runs properly under my patches for kForth. Is there
> > > a problem with the definition of TEST ?
>
> > It doesn't seem to be a standard Forth program.  What is the compiler
> > supposed to do with that 3 you left on the stack?
>
> > Andrew.
>
> More fundamentally, would the following be considered non-standard? If
> so, why?
>
> --
> Gforth 0.7.9-20101227, Copyright (C) 1995-2011 Free Software
> Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> : test [ 3 ] ;
> :1: unstructured
> : test [ 3 ] >>>;<<<
> Backtrace:
> $7FBC85886C28 throw
> $7FBC858972E0 c(abort")
> $7FBC858A48B0 def?
> $7FBC858904E8 ;-hook
> $7FBC8588E5C8 execute
> --
>
> Krishna

There's rubbish on the stack from the compilation between : and ;.
Many Forths complain about this, including Win32forth and mine. What
will pass is

3 : test [ ' two compile, ] - 1 = ;

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

#7513

On Nov 26, 5:08 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Nov 26, 8:14 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
>
>
> > On Nov 26, 11:36 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
>
> > > Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > > > I realized that the implementation of COMPILE, in kForth is broken. In
> > > > fixing the problem, I devised a few tests. However, the following test
> > > > does not seem to load in Gforth:
>
> > > > 2 constant two  ok
> > > > : test [ ' two compile, 3 ] - 1 = ;
>
> > > > Gforth fails to load the definition of TEST
>
> > > > --
> > > > :2: unstructured
> > > > : test [ ' two compile, 3 ] - 1 = >>>;<<<
> > > > Backtrace:
> > > > $7F6A74418C28 throw
> > > > $7F6A744292E0 c(abort")
> > > > $7F6A744368B0 def?
> > > > $7F6A744224E8 ;-hook
> > > > $7F6A744205C8 execute
> > > > --
>
> > > > The test loads and runs properly under my patches for kForth. Is there
> > > > a problem with the definition of TEST ?
>
> > > It doesn't seem to be a standard Forth program.  What is the compiler
> > > supposed to do with that 3 you left on the stack?
>
> > > Andrew.
>
> > More fundamentally, would the following be considered non-standard? If
> > so, why?
>
> > --
> > Gforth 0.7.9-20101227, Copyright (C) 1995-2011 Free Software
> > Foundation, Inc.
> > Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> > Type `bye' to exit
> > : test [ 3 ] ;
> > :1: unstructured
> > : test [ 3 ] >>>;<<<
> > Backtrace:
> > $7FBC85886C28 throw
> > $7FBC858972E0 c(abort")
> > $7FBC858A48B0 def?
> > $7FBC858904E8 ;-hook
> > $7FBC8588E5C8 execute
> > --
>
> > Krishna
>
> There's rubbish on the stack from the compilation between : and ;.
> Many Forths complain about this, including Win32forth and mine. What
> will pass is
>
> 3 : test [ ' two compile, ] - 1 = ;

The basic example I gave was,

: test [ 3 ] ;

Apparently, many implementations of Forth expect the stack to be
restored at ";" to the state following ";". Is this required by the
present Forth-94 standard?

Krishna

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

#7515

On Nov 26, 6:03 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
...
> : test [ 3 ] ;
>
> Apparently, many implementations of Forth expect the stack to be
> restored at ";" to the state following ";". Is this required by the
> present Forth-94 standard?
>

A typo -- I meant, "... restored at ';' to the state following ':'. "

Krishna

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

#7519

On 11/26/11 2:03 PM, Krishna Myneni wrote:
...
> Apparently, many implementations of Forth expect the stack to be
> restored at ";" to the state following ";". Is this required by the
> present Forth-94 standard?
>
> Krishna

In Forth94, : leaves a 'colon-sys' on the stack, and ; expects one.  The 
nature of a colon-sys is "implementation-dependent" meaning you don't 
know what it is (if anything).

The whole purpose of this is to permit compilers to check, if they wish, 
that nothing has been left on the stack at the end of a colon 
definition. That is valuable to people who, assuming that the 
control-flow stack is the data stack at compile time, use a data stack 
imbalance around a colon definition as a diagnostic of an incomplete 
control flow structure. Systems vary widely in the extent to which this 
is policed.

As an implementor, you're perfectly at liberty to ignore the whole 
thing, but programs that *assume* you can have an unbalanced stack 
around a : ... ; set are portable only to systems that also ignore 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]

#7520

On Nov 26, 9:10 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 11/26/11 2:03 PM, Krishna Myneni wrote:
> ...
>
> > Apparently, many implementations of Forth expect the stack to be
> > restored at ";" to the state following ";". Is this required by the
> > present Forth-94 standard?
>
> > Krishna
>
> In Forth94, : leaves a 'colon-sys' on the stack, and ; expects one.  The
> nature of a colon-sys is "implementation-dependent" meaning you don't
> know what it is (if anything).
>
> The whole purpose of this is to permit compilers to check, if they wish,
> that nothing has been left on the stack at the end of a colon
> definition. That is valuable to people who, assuming that the
> control-flow stack is the data stack at compile time, use a data stack
> imbalance around a colon definition as a diagnostic of an incomplete
> control flow structure. Systems vary widely in the extent to which this
> is policed.
>
> As an implementor, you're perfectly at liberty to ignore the whole
> thing, but programs that *assume* you can have an unbalanced stack
> around a : ... ; set are portable only to systems that also ignore 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 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Thanks for the clarification, Elizabeth. I had reached somewhat the
same conclusion, but you response helps. I think it can be agreed that
a program which creates an unbalanced stack between ":" and ";" is non-
standard under Forth-94.

What is your opinion of the use of COMPILE, in interpretation state,
while a word is being defined? Many systems seem to support this
behavior, although it is considered an ambiguous condition by DPANS94.
Should this be codified as a standard behavior in a future standard,
or would some Forth system architectures inherently be unable to
implement such behavior?

Krishna

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

#7521

On 11/26/11 5:33 PM, Krishna Myneni wrote:
...
> What is your opinion of the use of COMPILE, in interpretation state,
> while a word is being defined? Many systems seem to support this
> behavior, although it is considered an ambiguous condition by DPANS94.
> Should this be codified as a standard behavior in a future standard,
> or would some Forth system architectures inherently be unable to
> implement such behavior?
>
> Krishna

I'm afraid I'm not enough of a compiler guru to know all the 
consequences of using COMPILE, in interpretation state. It has been 
noted that it's meaningless unless you have a definition under 
construction, and I don't know how one could test for that -- it would 
be up to the programmer to know. And if the system's COMPILE, is capable 
of doing some sort of optimization, I can imagine difficulties. If your 
' finds different versions of words in compile mode, that would be an 
issue as well.

Not an awful lot of help, I'm afraid.

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]

#7530

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>What is your opinion of the use of COMPILE, in interpretation state,
>while a word is being defined? Many systems seem to support this
>behavior, although it is considered an ambiguous condition by DPANS94.

It's not.  The interpretation semantics of COMPILE, is not defined,
but the execution semantics are defined in a STATE-independent way.

So

: foo [ ' + compile, ] ; 

is not compliant, but

: my-compile, compile, ;
: bar [ ' + my-compile, ] ;

is compliant.

Some other interesting cases:

\ outside a definition
' + compile,

This is non-standard because of the lack of interpretation semantics
and because there is no current definition.

: [compile,] compile, ;
' + ] [compile,] [

This is non-standard because there is no current definition, but the
interpretation semantics of COMPILE, don't come into play here.

>Should this be codified as a standard behavior in a future standard,
>or would some Forth system architectures inherently be unable to
>implement such behavior?

Standard Forth systems must be able to implement COMPILE, with
interpretation semantics.  In fact it's trivial to convert a standard
system without interpretation semantics for COMPILE, into one with
interpretation semantics for COMPILE,:

: compile, compile, ;

This is a standard program, and a standard system is still standard
after this definition, but now it has a COMPILE, with interpretation
semantics.

So yes, we could remove the "undefined interpretation semantics"
clause.

- 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 2011: http://www.euroforth.org/ef11/

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

#7537

On Nov 27, 8:02 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> ...  The interpretation semantics of COMPILE, is not defined,
> but the execution semantics are defined in a STATE-independent way.
>

Not quite true for my (non-standard) system, as it performs a deferred
compilation even in interpretation state, so I have to switch the
virtual opcode vectors based on STATE. But, I see your point for
standard systems.

...
> Standard Forth systems must be able to implement COMPILE, with
> interpretation semantics.  In fact it's trivial to convert a standard
> system without interpretation semantics for COMPILE, into one with
> interpretation semantics for COMPILE,:
>
> : compile, compile, ;
>
> This is a standard program, and a standard system is still standard
> after this definition, but now it has a COMPILE, with interpretation
> semantics.
>
> So yes, we could remove the "undefined interpretation semantics"
> clause.
>

A good set of tests for COMPILE, which check compliance to the
existing Forth-94 standard, and provide extended tests for the
interpretation state behavior of COMPILE, would give us a starting
point to amend the spec.

Krishna

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

#7539

On Nov 26, 10:33 pm, Krishna Myneni <krishna.myn...@ccreweb.org>
wrote:
> I think it can be agreed that
> a program which creates an unbalanced stack between ":" and ";" is non-
> standard under Forth-94.

Or rather that they have an implementation dependency on ( colon-sys )
either not being on the data stack or being a nul (the latter perhaps
more common than the former). After all, the standard does not
*require* an implementation to balk at an unbalanced data stack
between ":" and ";",

Lots of things can be "standard but not necessarily very portable"
with declaration of the appropriate implementation dependencies.

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

#7527

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> The basic example I gave was,
> 
> : test [ 3 ] ;
> 
> Apparently, many implementations of Forth expect the stack to be
> restored at ";" to the state following ";". Is this required by the
> present Forth-94 standard?

Yes.

6.1.0450 :
colon CORE

	( C: "<spaces>name" -- colon-sys )

6.1.0460 ;
semicolon CORE

	Interpretation: Interpretation semantics for this word are undefined.

	Compilation: ( C: colon-sys -- )

colon-sys is some number of items on the stack.  If you put something
on the stack after : , you must remove it before ; .  That's what the
colon-sys implies.

Andrew.

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

#7497

Krishna Myneni <krishna.myneni@ccreweb.org> wrote Re: Test of COMPILE,
[..]
> 2 constant two  ok
> : test [ ' two compile, 3 ] - 1 = ;
[..]
> Gforth fails to load the definition of TEST
[..]

Don't you mean 

2 constant two 
: test [ ' two compile, 3 ] literal 1- = ;

Accepted by Win32Forth, VfxForth, SwiftForth and gForth.

iForth rejects it because the interpretation semantics of
COMPILE, are undefined. After : COMPILE, COMPILE, ; it 
`works` to.

All compilers accept ...

: test [ ' two compile, -12 allot 3 ] literal 1- = ;

... with various interesting results. E.g. VfxForth seems not 
to notice the -12 allot at all, SwiftForth exits silently and 
gForth gives a good error report (It has head damage but not
critical).

-marcel

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

#7500

On Nov 26, 10:41 am, m...@iae.nl (Marcel Hendrix) wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote Re: Test of COMPILE,
> [..]> 2 constant two  ok
> > : test [ ' two compile, 3 ] - 1 = ;
> [..]
> > Gforth fails to load the definition of TEST
>
> [..]
>
> Don't you mean
>
> 2 constant two
> : test [ ' two compile, 3 ] literal 1- = ;
>
> Accepted by Win32Forth, VfxForth, SwiftForth and gForth.
>
> iForth rejects it because the interpretation semantics of
> COMPILE, are undefined. After : COMPILE, COMPILE, ; it
> `works` to.
>

Ah! Ok, I missed the spec where it says interpretation semantics of
COMPILE, are undefined. That explains the different behavior in
different systems. I was confused by the original mini-oof word "::"
which is defined with COMPILE, but "::" itself is used in
interpretation state, as in the mini-oof example,

:noname bold [ button :: draw ] normal ;

where the definition of "::" is

: :: ( class "name" -- ) ' >body @ + @ compile, ;

Krishna

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

#7506

Krishna Myneni wrote:
>> iForth rejects it because the interpretation semantics of
>> COMPILE, are undefined. After : COMPILE, COMPILE, ; it
>> `works` to.
>>
> 
> Ah! Ok, I missed the spec where it says interpretation semantics of
> COMPILE, are undefined. That explains the different behavior in
> different systems. I was confused by the original mini-oof word "::"
> which is defined with COMPILE, but "::" itself is used in
> interpretation state, as in the mini-oof example,
> 
> :noname bold [ button :: draw ] normal ;
> 
> where the definition of "::" is
> 
> : :: ( class "name" -- ) ' >body @ + @ compile, ;

To be honest, I don't understand why the interpretation semantics of 
compile, is declared undefined.  compile, needs a current definition, 
yes, but that's it.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#7509

On Nov 26, 2:31 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Krishna Myneni wrote:
> >> iForth rejects it because the interpretation semantics of
> >> COMPILE, are undefined. After : COMPILE, COMPILE, ; it
> >> `works` to.
>
> > Ah! Ok, I missed the spec where it says interpretation semantics of
> > COMPILE, are undefined. That explains the different behavior in
> > different systems. I was confused by the original mini-oof word "::"
> > which is defined with COMPILE, but "::" itself is used in
> > interpretation state, as in the mini-oof example,
>
> > :noname bold [ button :: draw ] normal ;
>
> > where the definition of "::" is
>
> > : :: ( class "name" -- ) ' >body @ + @ compile, ;
>
> To be honest, I don't understand why the interpretation semantics of
> compile, is declared undefined.  compile, needs a current definition,
> yes, but that's it.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

If it's an arbitrary restriction, but there is in reality no problem
for system implementors to give interpretation semantics when a colon
definition is in progress, then we should look at revising the
standard.

Krishna

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

#7531

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>I was confused by the original mini-oof word "::"
>which is defined with COMPILE, but "::" itself is used in
>interpretation state, as in the mini-oof example,
>
>:noname bold [ button :: draw ] normal ;
>
>where the definition of "::" is
>
>: :: ( class "name" -- ) ' >body @ + @ compile, ;

Note that the compilation sematics of COMPILE, does not come into play
here; COMPILE, is performed by the text interpreter in compile state,
so the compilation semantics of COMPILE, is performed.  Later, during
execution of ::, the execution semantics of COMPILE, is performed.
This is just like

: compile, compile, ;

- 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 2011: http://www.euroforth.org/ef11/

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

#7501

On Nov 26, 4:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> wrote Re: Test of COMPILE,
> [..]> 2 constant two  ok
> > : test [ ' two compile, 3 ] - 1 = ;
> [..]
> > Gforth fails to load the definition of TEST
>
> [..]
>
> Don't you mean
>
> 2 constant two
> : test [ ' two compile, 3 ] literal 1- = ;
>
> Accepted by Win32Forth, VfxForth, SwiftForth and gForth.
>
> iForth rejects it because the interpretation semantics of
> COMPILE, are undefined. After : COMPILE, COMPILE, ; it
> `works` to.
>
> All compilers accept ...
>
> : test [ ' two compile, -12 allot 3 ] literal 1- = ;
>
> ... with various interesting results. E.g. VfxForth seems not
> to notice the -12 allot at all, SwiftForth exits silently and
> gForth gives a good error report (It has head damage but not
> critical).
>
> -marcel

My compiler optimizes the whole lot away in the first case, and does
what's asked of it in the second case. That's because the headers and
the code are maintained in separate sections from data at HERE.

STC Experimental Version: 0.05.01 Build: 439
2 constant two  ok
: test [ ' two compile, 3 ] literal 1- = ;   ok
test . -1  ok
see test
: test ( ? -- ? )               \ std call compiles
                                \ len=9 type=20
                                \ in (console)
( $424114 ' test )              mov   $-4 [ebp], eax         \ 8945FC
( $424117 ' test+$3 )           or    eax, # $-1             \ 83C8FF
( $42411A ' test+$6 )           sub   ebp, # $4              \ 83ED04
( $42411D ' test+$9 )           ret   near                   \ C3
( end ) ok

here . 8414048  ok
: test [ ' two compile, -12 allot 3 ] literal 1- = ;
      ^
Warning -4100 test is redefined  ok
here . 8414036  ok
test . -1  ok

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web