Re: An Observation

On Mar 19, 5:53 pm, Elizabeth D Rather <erather...@xxxxxxxxx> wrote:

Standard Forth splits it up in a way that makes sense to implementors
and people who think like implementors -- advanced users. CHAR is a
regular word like + . You execute it now or you execute it later. It
does one thing.

Well, I just returned from teaching a beginning Forth class last week.
Two of my students had little or no programming background, and the rest
were entirely new to Forth. They certainly don't think like
implementors. I explained CHAR and [CHAR] as I did in my prior post in
this thread, of which John quoted only the beginning. None of them had
any problem with using both words appropriately, or making the
distinction between them. So I don't think this is either advanced,
complex, or confusing.

I'm glad that you are good at teaching it, I also have taught this
successfully. But the way I understand it, the troubles Forth had with
state-smart words came when naive users naturally expected things
like CHAR W to work the same inside definitions as they did at the
command line. And so the temptation was to give them what they wanted
and expected. Careful training can avoid that problem, but arranging
Forth systems to avoid the problem in the first place is better than
careful training.

Various people have tried setting up Forths that always compile and
then execute temporary nameless definitions instead of interpreting.
Every one I've heard of started out with the hope that it would be
simpler, and every one of them then decided that it only moved the
complexity around and was not actually any simpler. Dr. Ting is the
only one I remember the name of, who went through that cycle. But they
were all creating Forths that were pretty much traditional apart from
always compiling. I'd like to hope that maybe by giving up some other
complexity it might be possible to always-compile and actually have it
simple. But I'm not there yet.

Frankly, if CHAR were a STATE-smart IMMEDIATE word, I might very well
have trouble explaining how to do a function like this:

: SEE-CHAR ( -- ) CHAR . ;
SEE-CHAR A 65

I'd have to introduce POSTPONE, which I rarely do in intro classes (I
don't introduce STATE, either).

Agreed! That approach just didn't work out well. Piling extra
complexity on just tangled it further, and [CHAR] is much better than
the old state-smart CHAR .

The original issue was whether LSE64 could be implemented portably in
Standard Forth. It cannot, because of the sloppiness of the standard.

Why can't it? Maybe the result can't be completely portable because it
might depend on behaviors that aren't completely portable. But even in
that case there might be a version that's largely portable, and other
versions that work for other Forths. I haven't seen anything yet that
I'm sure says it's impossible.

Standard Forth is intended for developing applications. I don't think
it's possible to implement Standard Forth in Standard Forth, and don't
think inability to implement LSE64 in Standard Forth is conceptually
different.

When SLITERAL was added to the standard, Mitch Bradley told me with
some satisfaction that that had been the last thing missing that had
prevented implementing Standard Forth in Standard Forth. I haven't
implemented Standard Forth in Standard Forth to check whether he was
right.

.

Relevant Pages

  • Re: Destructor: not gauranteed to be called?
    ... >>> the ToStringmethod to a Char[] it returns with the EXACT SAME ... >>> the standard and might break someone's existing code. ... ToString is not part of the C++ ... The fact yhat you require or expect a Charto act as a string is a sign ...
    (microsoft.public.dotnet.languages.vc)
  • Re: byte order
    ... int am_i_little_endian{ ... Are you *absolutely* sure that's standard C, ... assuming a 8-bit char). ... The pointer casting rules specify that "It is guaranteed that ...
    (comp.lang.lisp)
  • Re: I want unsigned char * string literals
    ... within the text one should cast to unsigned char first. ... The original Standard tried to codify ... useless at this point. ... locale - no context object so it can't be safely used in libraries ...
    (comp.lang.c)
  • Re: Crazy stuff
    ... >>and the C standard states that it has the type array of char. ... C does not define "memory areas" at all. ...
    (comp.lang.c)
  • Re: An Observation
    ... Standard Forth splits it up in a way that makes sense to implementors ... You execute it now or you execute it later. ... Alternatively, you can compile CHAR into a command to execute later, ...
    (comp.lang.forth)
Loading