[comp.lang.forth] BASIS 14... comments

UNBCIC@BRFAPESP.BITNET (12/01/90)

> Summary of BASIS 14 Changes (John Rible's unofficial report)

> Added Words:
> To Core ext;
> CASE OF ENDOF ENDCASE
To CORE??? Extended Core would be better. Anyway, what is the stack behavior?

> REFILL
What it does?

> COMPILE
So, we have COMPILE but we don't have [COMPILE] ... and we have POSTPONE also,
that's right?

> C" MS MARKER
What they do?

> To File; SAVE-INPUT RESTORE-INPUT FILE-STATUS
What they do?

> WRITE-LINE
Instead of WRITE-CR ? So WRITE-CR now can be defined as a WRITE-LINE with an
empty string?

> RESIZE-FILE REPOSITION-FILE
What they do? Exactly, I mean...

> To File ext; FLUSH-FILE

> To Float ext; F"
Yes? What it does?

> To Double; D0<
> To Programmer; BYE KEY?
Fine!

> Deleted Words:
> From File; WRITE-CR

> SEEK-FILE
Oh, oh! Why?

> From File ext; EXTEND-FILE
> From Non-portable; ?KEY ?EKEY

> Renamed, Redefined, or Moved Words:
> BL from Core ext to Core

> " renamed S" in Core and Programmer
Why?

> -TRAILING from Core ext to String
> QUERY restored to traditional meaning in Core ext
> .( 0> from Core to Core ext
> PARSE redefined so address is in the input stream, moved from Core to Core
> ext
> LIST from Non-portable to Block
> ONLY ALSO PREVIOUS ISOLATE from Search to Search ext
Yeah.

> ORDER from Non-portable to Search ext
Problems. My programs often use ONLY and ALSO, but never ORDER. With ORDER I
need the name (string)... and now the ANS Compatibles can't tell me that I have
ONLY and ALSO if they don't have ORDER. But I'll not lost my sleep...

> [COMPILE] made "non-obsolescent" in Core ext
??? Can someone explain this to me with more words?

> FILEPOS is FILE-POSITION and FILESIZE is FILE-SIZE in File
> BLOCK-FILE is FILE-BLOCK and BUFFER-FILE is FILE-BUFFER in File ext
> RENAME-FILE from File to File ext
Ok.

> Other Changes:
> Non-portable word set renamed "Programmers toolkit" word set
I like this!

> Cell and Floating-point number sizes are intregal multiples of character size
> Nested compilation of definitions is disallowed
??? What this mean? What are the pratical effects?

> Beyond scope of Standard to specify termination condition of ACCEPT or EXPECT
:-((((( But I can understand.

> Only graphic characters (from ISO-IRV, ASCII) from 32...126 within scope of
> standard
Yeah.

> "Error" codes -1...-255 reserved fro ANSI, -256...-4095 for system
Great!!!

> New data type taxonomy permits address, character, and other mixed type
> arithmetic
:-) Although I shouldn't use this.

> Much new text added for rationale and implementor's guide apendices
Good.

> Many typos and format problems corrected
;->

> Some statistics:
> 958 proposals received (194 from outside the committee, 1/3rd of which
> passed)
> 518 proposals passed (246 were amended)

> 18 proposals still pending
Oh no! :-)

> estimated over $300,000 direct expenditures, plus over $500,000 volunteer
> time
Thanks to everyone!

> DRAFT PROPOSED ANSI FORTH STANDARD EXPECTED AFTER NEXT MEETING
:-))))))))))))))))))))))))))))))))))))))

> We are expecting to have BASIS 14 ready for release by December 10th.
Ok. But I think somewone should convert it to TeX. There is a WP -> TeX
translator at Simtel. Imagine if we can find a RTF -> WP translator!!!

                              (8-DCS)

wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (12/01/90)

> > Summary of BASIS 14 Changes (John Rible's unofficial report)

> > Added Words:
> > To Core ext;
> > CASE OF ENDOF ENDCASE

> To CORE??? Extended Core would be better. Anyway, what is the stack behavior?

"Core ext" is Extended Core.  The committee changed its mind about whether
the "EXT" goes before or after the base wordset name.


> > REFILL
> What it does?

It's like QUERY, but it returns a flag denoting whether or not the operation
succeeded.  In other words, an end-of-file flag.


> > COMPILE
> So, we have COMPILE but we don't have [COMPILE] ... and we have POSTPONE
>  also, that's right?

[COMPILE] and POSTPONE are in CORE, COMPILE is in CORE EXT


> > C" MS MARKER
> What they do?

C"  ( "string" -- adr )
        Compiles a counted string  ( " has been renamed to S" )

MS  ( n -- )  Delays at least n milliseconds

MARKER  ( "name" -- )
        Defines a word that, when later executed, empties the dictionary
        back to where it was before MARKER was executed.  This can also
        clean up other resource allocations, such as the user area, and
        unlink any linked structures that the compiler maintains.


> > To File; SAVE-INPUT RESTORE-INPUT FILE-STATUS
> What they do?

SAVE-INPUT  ( -- w1 w2 w3 )
RESTORE-INPUT  ( w1 w2 w3 -- flag )

        SAVE-INPUT remembers the current input stream position on the stack
        and RESTORE-INPUT restores the input stream to a previously-saved
        position.  The flag tells whether or not it succeeded.

FILE-STATUS  ( adr len -- false | w true )

        If the named file exists, returns true and an implementation-
        defined number "w" giving additional system-dependent information
        about the file.  Otherwise returns false.  For example, under
        Unix, "w" would be the address of a "stat" struct.

> > WRITE-LINE
> Instead of WRITE-CR ? So WRITE-CR now can be defined as a WRITE-LINE with an
> empty string?

Yes.


> > RESIZE-FILE REPOSITION-FILE
> What they do? Exactly, I mean...

RESIZE-FILE changes the file size, truncating or extending as necessary.
This operation may fail on some operating systems.

REPOSITION-FILE  is like SEEK but the position is always absolute.  If
you want to do relative seeking or seeking backwards from the end, you
have to call FILE-SIZE or FILE-POSITION and do some arithmetic.

> To File ext; FLUSH-FILE

> > To Float ext; F"
> Yes? What it does?

That should be F~ (tilde, not quote).  It means "approximately equal".
There is an argument that, if positive, is the absolute value of the
allowable difference, and if negative, is the relative difference.

> Deleted Words:
> From File; WRITE-CR

> > SEEK-FILE
> Oh, oh! Why?

Replaced by REPOSITION-FILE , which is easier to use and more
straightforward in most cases.


> > " renamed S" in Core and Programmer
> Why?

Some existing systems use " to mean the address of a counted string,
others use it to mean an "adr len" string.  We didn't want to break
existing code.


> > ORDER from Non-portable to Search ext
> Problems. My programs often use ONLY and ALSO, but never ORDER. With ORDER I
> need the name (string)... and now the ANS Compatibles can't tell me that
> I have ONLY and ALSO if they don't have ORDER. But I'll not lost my sleep...

Not true.  An implementation can provide selected words from a wordset,
so long as it documents it clearly, e.g. "includes the words ONLY and ALSO
from the SEARCH ORDER EXTENSION" wordset".  It can also provide some words
in source form.


> > [COMPILE] made "non-obsolescent" in Core ext
> ??? Can someone explain this to me with more words?

"Obsolescent" means the word will automatically go away in the next
standard (years from now) with no explicit action necessary.  Making
[COMPILE] non-obsolescent means that it will NOT automatically go away.

By the way, now that we have COMPILE, (compile-comma), the words
POSTPONE , [COMPILE] , and COMPILE are all unnecessary, as the desired
effects may be achieved with  ['] foo EXECUTE   and  ['] foo COMPILE,


> > Cell and Floating-point number sizes are intregal multiples of character
> > size.  Nested compilation of definitions is disallowed
> ??? What this mean? What are the pratical effects?

The integral multiple thing implies that it is possible to store cell values
and floating point values within files and arrays.  Without that restriction,
it wasn't clearly possible.

Disallowing nested compilation means that a Standard Program can't do
something like:

        : FOO
            LOCAL x  LOCAL y
            [ START:  ]  LOCAL x  LOCAL y
            [COMPILE] ;
        ;

In other words, the compiler loop in a Standard System is not required
to be re-entrant.  (Nestable compilers are not disallowed, but a portable
program may not assume that the compiler is itself nestable).


> > Beyond scope of Standard to specify termination condition of ACCEPT or
> > EXPECT
> :-((((( But I can understand.

For the benefit of those who may not understand, the function of ACCEPT
and EXPECT, so far as a program is concerned, is to deliver an input line
of at most n characters.  The precise set of user actions necessary to
prepare and terminate that line is not specified by the standard.  The
line editing function is often under the control of an external operating
system, and cannot always be modified by the Forth system implementor.

Basis 14 will *recommend* some behavior, such as "an explicit <return> should
be required, rather than automatically 'waking up' after n characters",
but that will not be a required behavior.


> > 18 proposals still pending
> Oh no! :-)

Multitasking is still pending.  Should be an interesting discussion!


Mitch Bradley, wmb@Eng.Sun.COM

wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (12/03/90)

> But what is the stack behavior [of the CASE construct] ?
> I see now that there is no OTHERWISE

This is the "classic" Eaker case statement as described in Forth Dimensions
volume 1.  It's the winner of the "Great Forth Dimensions Case Contest".

CASE  ( selector -- selector )

OF    ( selector match-value -- )            if match
OF    ( selector match-value -- selector )   otherwise

ENDOF ( -- )                    if preceding OF matched
ENDOF ( -- selector )           otherwise

ENDCASE  ( selector -- )

The "otherwise" case is implicit.

Example:

: CARDNAME  ( n -- )
   CASE
      1 OF  ." Ace"   ENDOF
      2 OF  ." Deuce" ENDOF
      3 OF  ." Trey"  ENDOF
     11 OF  ." Jack"  ENDOF
     12 OF  ." Queen" ENDOF
     13 OF  ." King"  ENDOF
     ( n )  DUP .  ( n )
   ENDCASE
;

The "default" code ( "dup ." in this example) is optional.  Note that
the default code must take care to leave something on the stack for
ENDCASE to drop.

This case statement has its faults, but it has its virtues too.  It's a
good tradeoff.  I use it a lot.  Sometimes a "jump table" case statement
is better, sometimes not.  Eaker's case statement definitely has a lot
of common practice behind it.


> You didn't understand my point. See, let's say that I have an ANS compatible
> Forth, with some extension wordsets. One day, I find in a BBS a very useful
> program (routine...) written for ANS Forth Standard. I download it and then:
>
> 1) I just run it. It will tell me if it can run on my system.
> 2) Analize the code, so I can see if I can run it on my system.
>
> Providing ONLY and ALSO is easier than ORDER....

I'm sorry, I'm still not sure that I understand.  Are we perhaps talking
about a different meaning of ORDER ?  ANS ORDER displays the search order
for the programmer's benefit.  It's a debugging tool.  I don't find it
particularly difficult to implement.  I think I must be missing something.


> Yeah. What are the cons against MULTI, SINGLE, PAUSE, WAKE, SLEEP
> cooperative multitasking? I know that someone may need time-slice,
> but we could provide two Multitasking wordsets... Different needs...

I anticipate that the discussion will proceed as follows:

1) The desire for a wordset that can encompass both cooperative and
   preemptive multitasking will be aired.

2) Technical arguments will be voiced to the effect that this is
   impractical.  These arguments are likely to be compelling.

3) The discussion will then focus on the particular wordset to implement
   cooperative multitasking.

4) It will go around and around and around for a while.

5) There will be tension between those who favor a wordset complete enough
   to actually write a complete portable program, and those who wish to
   minimize the number of words.  The "completeness" advocates, regardless
   of whether they are right or wrong, will face the problem that more
   words means longer discussion and more chance of the whole thing getting
   tabled due to brain cell burnout.

6) The discussion will focus back on Grag Bailey's proposed minimal
   helpful-but-in-itself-incomplete wordset.

7) I will air my usual gripe about words that create new closures
   (in this case ACTIVATE< , which sends the rest of the colon definition
   after it to a task).  I really don't like "2 definitions in one"
   structures (I don't like the syntax of DOES> , and I don't like
   Brodie's DOER .. MAKE )

8) I will probably eventually back down under Greg's penetrating stare,
   and then the argument over the names will ensue.  For example, the
   "<" at the end of "ACTIVATE<" is likely to bum out some people (me
   included).

As for the final outcome, your guess is as good as mine (well, maybe not;
I can probably eliminate a few unlikely possiblities based on past
experience.  But hey; I've been surprised several times, so maybe I take
that back.)


> I'm interested in C Forth. Can you send the Bradley software address? I think
> I had lost it...

Bradley Forthware, P.O. Box 4444, Mountain View, CA 94040


Cheers,
Mitch Bradley, wmb@Eng.Sun.COM

john@aplcomm.jhuapl.edu (John Hayes) (12/04/90)

Mitch Bradley writes:
> By the way, now that we have COMPILE, (compile-comma), the words
> POSTPONE , [COMPILE] , and COMPILE are all unnecessary, as the desired
> effects may be achieved with  ['] foo EXECUTE   and  ['] foo COMPILE,

   This is true but the results of such an implementation would be
inefficient on native code systems.  The problem is that a postfix
COMPILE, (compile-comma) operator has less information available
to it than a prefix POSTPONE operator.  I offer two examples:

1)  Some native code systems have a compiler vocabulary with
compile-time versions of many primitives (e.g. DUP).  This compile
time DUP, compiles top-of-stack duplication code and may apply
peephole optimization.  An ordinary version of DUP appears in the
user visible vocabulary; ['] returns this 'ordinary' DUP.
   ['] DUP COMPILE,
compiles a subroutine call to DUP; the COMPILE, (compile-comma) does
not have enough information to inline the DUP.

2)  Some native code systems store information in a definition's header
to determine whether that definition should be inlined or or called as
a subroutine.  The compiler's internal equivalent of COMPILE, (compile-comma)
given the execution address of a definition, computes the address of the
data in the header.  A user accessible COMPILE, (compile-comma) may not assume
that the execution address belongs to a definition with a header;
START: allows the construction of headerless code.  Therefore, COMPILE,
(compile-comma), must always compile a subroutine call.  Again, COMPILE,
(compile-comma) does not have the necessary information.

   I assert that POSTPONE is the fundamental operator.
POSTPONE is used for more often than COMPILE, (compile-comma) and
[COMPILE] in programs.  Therefore, it should be as efficient as possible.
By being prefix, it has the opportunity to use the name following it
in the input stream to extract the necessary information.
COMPILE, and [COMPILE] can be defined:
   : COMPILE,  POSTPONE LITERAL POSTPONE EXECUTE ;
   : [COMPILE]  ' COMPILE, ; IMMEDIATE

John R. Hayes			john@aplcomm.jhuapl.edu
Applied Physics Laboratory
Johns Hopkins University

wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (12/05/90)

The following is a good example of the kinds of disagreement that can
occur within the ANS Forth committee.  In committee, the disagreement
is often not as polite as you will see here :-)

The issues are often subtle, and frequently there is no clear "right"
answer.


> Mitch Bradley writes:
> > By the way, now that we have COMPILE, (compile-comma), the words
> > POSTPONE , [COMPILE] , and COMPILE are all unnecessary, as the desired
> > effects may be achieved with  ['] foo EXECUTE   and  ['] foo COMPILE,
>
> John Hayes writes:
>    This is true but the results of such an implementation would be
> inefficient on native code systems.  The problem is that a postfix
> COMPILE, (compile-comma) operator has less information available
> to it than a prefix POSTPONE operator.  I offer two examples:

The validity of the cited examples depends upon the assumption that
the implementation cannot correlate the interpretation and compilation
behaviors of immediate words.  The lack of such correlation could
be viewed as a weakness of certain implementation techniques.

All implementation techniques have advantages and disadvantages.

Even with implementation techniques as described in the examples,
it is possible to provide the linkage between compilation and
interpretation behaviors.  It costs a little memory, but that
is just a tradeoff like any other tradeoff.


> POSTPONE is used for more often than COMPILE, (compile-comma) and
> [COMPILE] in programs.

[COMPILE] appears in several previous standards, and in every Forth
implementation I have ever used.  POSTPONE appears in none of them.

I therefore dispute the statement as written.  It may well be that,
in the post-ANS future, POSTPONE *will be* used far more often than the
alternatives, but I don't think that is true in the present tense.


> I assert that POSTPONE is the fundamental operator.

I disagree, based on the fact that the meaning of a name is ambiguous (it
depends on the current search order), whereas the meaning of an execution
token is not.  Also, I view POSTPONE as being an (admittedly useful)
construct built from the primitive functions "lookup" (i.e. FIND ),
"compile" (i.e. COMPILE, ), and "execute" (i.e. EXECUTE ).

I think the crux of this discussion depends on what one expects from
an execution token.  In my world view, an execution token (previously
known as a CFA) should be a number that identifies a particular word,
and from which the system can infer everything that is necessary to
known about that word.  Another world view sees an execution token
as something that you can pass to EXECUTE , no more, no less.

I justify my viewpoint based on the aforementioned ambiguity argument.
I believe that an unambiguous word identifier should exist, and the
execution token is the only currently viable candidate (because that
is what FIND returns).  Other candidates might be possible, but none
have been proposed.

Mitch Bradley, wmb@Eng.Sun.COM

rob@innovus.UUCP (Rob Sciuk) (12/05/90)

In article <9011302139.AA09487@ucbvax.Berkeley.EDU> UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV writes:
>> Summary of BASIS 14 Changes (John Rible's unofficial report)

	much stuff deleted ...

>> We are expecting to have BASIS 14 ready for release by December 10th.
>Ok. But I think somewone should convert it to TeX. There is a WP -> TeX
>translator at Simtel. Imagine if we can find a RTF -> WP translator!!!
>
>                              (8-DCS)

	ditto the TeX version !!!! (or Troff)
rss.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Sciuk	rob%innovus@maccs.dcss.mcmaster.ca
Innovus Inc.	204-200 James St S. Hamilton, Ont. 	Phone:	(416) 529-8117 
		{not a flame ... merely a glimmer ...}	Fax:	(416) 572-9586	
<<< Note:  to avoid routing problems do not r(eply), use my address as above >>>