Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: (none)
Message-ID: <14130@medusa.cs.purdue.edu>
Date: 31 Mar 91 21:33:57 GMT
References: <9103301533.AA22551@ucbvax.Berkeley.EDU>
Sender: news@cs.purdue.EDU
Organization: Department of Computer Science, Purdue University
Lines: 93

>>It would inspire a bit more
>>confidence if the people so articulate about what they want changed
>>could also articulate their understanding of qualities that should be
>>preserved.
 
In article <9103301533.AA22551@ucbvax.Berkeley.EDU> wmb%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes:
>Okay.  Here's what should be preserved in Forth:

  Mitch, you haven't been very articulate about wanting changes!
 
>1) Parameter passing on a visible stack

  The two things I like most about Forth are the parameter passing and
  the simplicity of the TI implementation.

>2) The names and semantics of common operators (corresponding to the
>   ANS CORE wordset)

  Doesn't matter to me what the name of a word is as long as it relates
  in some way to what the word does.

>3) The very simple lexical structure (i.e. white space is the only
>   "magic" character, and you can use any other character in a name).

  Disagree with this in part as it is too severe a restriction.  For eg.
  in my Forth systems I like to have a "read dispatching character".  Forth
  already has the distinction between words that run at compile and run
  time.  I have extended this to have also read time words.  The triggering
  mechanism for the reader is a special character.  In my system I use '#'.

  Using this mechanism I can define load time conditionals very easily.

  : #:if 0 = if { read past corresponding #else or #then } then ;
  : #:else { read past corresponding #then } ;
  : #:then ;

  I also use it to define the syntax of numbers in different bases.
  Given a definition something like

  : #:o input-base @ 8 input-base ! text number swap input-base ! ;

  #o12 is now recognized as the decimal number 10.

  In my system ' " , | \ : are all special characters as well.  I really 
  don't see how this hurts anything.

>4) The ability to redefine anything you want

  Yes, but I don't think the current standards of Forth take this far enough.
  The way it is now if I have : B A ; and I redefine A, B still uses the old
  definition of A.  Fine, but I would like the OPTION of redefining the old
  definition as well.  Why?  Because when I redefine A I should not have to
  recompile all the definitions of the words that reference it.

>5) The inherent "programming environment" model, i.e. you don't run the
>   compiler, then run the program; you program by interacting with the
>   environment.

  What I said under #4 applies here.  The way it is now, you do have to re-
  run the compiler on any words that reference a changed definition.

>6) The lack of a fundamental distinction between system-supplied
>   and user-supplied functions.

  Again apply #4.  Dangerous? yes.  Powerful? yes!

>7) The lack of language-enforced data typing (data typing is a useful
>   thing, but adding it to Forth would compromise Forth's simplicity,
>   efficiency, and malleability; leave data typing to other languages
>   (which may or may not be implemented on top of Forth))

  Big mistake!  "enforced" holds nasty freedom-restriction conotations.
  Automatic type checking should always be possible to turn on and off at
  will.  With it off, and the proper renaming of a few words you can have
  a system identical to what you got now.  If that's what you really want.

>8) The ability to implement a useable Forth system on a small machine.

  What do you consider a "small machine" these days?  Since I consider any
  machine with less than 4M RAM too small to be worth using, I agree.  My
  system which has everything I describe here and more takes 250k.

>Most of the things that I want changed fall into the category of standard
>extensions, the addition of which has no effect on the fundamental nature
>of Forth.

  Me too.  There are a couple of fundamental changes I want, though.  Each
  word should optionally contain a vocabulary in addition to whatever else
  it does.  The notion of the dictionary growing in contiguous memory has
  got to go.  I have discussed these in detail in the past.  I consider
  such things also to be "extensions", though, in the sense that a system
  that has them can be made to behave identically to the way Forth does now.
  People are always free not to use all of the stuff available to them.