[comp.lang.forth] Base specification standard

DJS%UTRC@UTRCGW.UTC.COM (David Sirag) (01/18/90)

From:    David J. Sirag ( DJS )                  Postmark: 18-Jan-1990 10:29am
Dept:    Adv Software Technology                 Tel No:   8-446-7429

TO:  Remote CSnet User                    (
 _IN%ZMLEB%SCFVM.BITNET@CUNYVM.CUNY.EDU )


Subject: RE: Base specification standard

It seems to me that selecting an actual standard, that will actually become
STANDARD, is going to be almost impossible considering the diversity of
suggestions already presented on this list. Therefore instead of selecting
a specific standard syntax, why not select a standard way to describe the
syntax that will be used in the current file (or screen, or word, etc.).

For example:

The word PREFIX-BASE could indicate that any subsequent numbers will be
preceded by the base indicator. POSTFIX-BASE could reverse this temporary
standard.

BASE-INDICATOR 16 H
  could indicate that the character H will subsequently be the base
indicator for hex.
BASE-INDICATOR 16 $
  would subsequently change this declaration to use $ instead
BASE-INDICATOR 16 J
  could even be used by anyone out there strange enough to think that J is
the nicest looking delimiter for hex.

The BASE-INDICATOR word should be defined to work for ANY base and for any
character or word. Why not allow:
BASE-INDICATOR 16 HEX

Similarly, ATTACHED-BASE and UNATTACHED-BASE should declare whether the
base indicator should adjoin the number directly or whether it is a
seperate word.


The implementation issues for these words would of course be left up to the
Forth language developer, although I can think of several alternatives
which trade off execution speed vs. code size. Actually, I don't believe
that execution speed for these words is critical, because of the way I
imagine them being used. I would imagine that, since each programmer seems
to have his own preference for notation, each section of code written by
that programmer would begin with the above declarations taylored to
indicate his style. I believe that these style changes would occur
infrequently, and so would not clutter up the code. On the other hand, they
would allow an outside observer to quickly determine the syntax of the
following code, and should provide simple portability.

     I hope these suggestions are useful.

                                David Sirag
                                DJS%UTRC@UTC.COM