Re: [stack] the concatenative wikipedia article

pml060912 <[email protected]> wrote:
> "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>> I think the use of
>> "Reverse Polish Naming" is blocking my understanding -- I can't tell
>> when a word I don't recognize is intended to be a definition versus
>> when it's simply unfamiliar to me.

> I can see how that would matter for following someone else's code, not
> so much for the coding process itself.

If I come back to the same code tomorrow, it might as well be somebody
else's code :-).

> I was thinking of addressing it
> with compiler warning messages and a prettyprinting standard for
> coding (it would be easy for the compiler to generate that as part of
> a log).
> In my examples I've tried to separate code that way, so each
> "paragraph" (maybe only one line) either ends with a definition or is
> the last one (which will be run). Maybe I need to be clearer and
> double check that there is always an "and run" paragraph for each
> example or a clear indication that I'm not providing one (technically,
> I am - a null one).

I'm really not understanding 90% of what you're saying, so the
following is just a guess. I *think* you're proposing that Furphy be
made whitespace-sensitive, so that definitions have to/are recommended
to fall within certain formats. This reminds me of ColorForth, and I'm
in favor of it.

On the other hand, I'm not in favor of warning messages for syntax. If
you're going to make the compiler take cues from whitespace, make them
the ONLY cues it takes. For example, suppose that you wanted to make a
definition (by convention) be the last word in a paragraph; in that
case, set up the compiler so that if a word's terminated by a newline
it's automatically treated as a definition, and if the word's already
defined it's an error. I don't like that convention, but it'd work.
I'd prefer a visible convention, for example creating a label every
time a word begins on column zero (so definition names would be
against the left margin, and everything else would be indented). An
even more graceful requirement would be to use a visible character
tacked onto the desired definition, like a colon or equals sign.

> This comes as part of the larger problem of making typos - the low to
> zero amount of syntax means that the compiler doesn't enforce/catch
> things as much as many languages would. But I want to stay with the
> Forth spirit of trusting and enabling the programmer, so I think
> warnings for each new word are enough.

A compiler that trusts the programmer doesn't feel the need to emit
warning messages.

You definitely have gotten rid of an annoyance in Forth by inventing
this modeless compiler; but I think your first solution isn't as
modeless as you think. Instead of having one state variable, its state
is the entire dictionary.

> Also, I don't want to introduce
> "special" handling that would bring back modes or the equivalent,
> except as syntactic sugar like the quotation system, to keep the
> fundamentals simple and consistent. So I'll give some thought to
> syntactic sugar for naming, i.e. something that could be handled by a
> preprocessor even though actual implementation would use immediate
> keywords to integrate it with the compiler - suggestions welcome.

Some examples are above :-). My preference is the visible character
attached to the definition -- perhaps an equals sign at the beginning
of the word, since your words appear after the thing they define.

And by the way, your solution is extremely modal, according to
Raskin's definition: "An human-machine interface is modal with respect
to a given gesture when (1) the current state of the interface is not
the user's locus of attention and (2) the interface will execute one
among several different responses to the gesture, depending on the
system's current state." (Raskin, "The Humane Interface", Page 42,
cited on Wikipedia). The "gesture" is typing a word, and the system's
current state is what words are currently defined. Because of the size
of the state, it's impossible to have the state ever be the locus of
the user's attention; thus, there will be a lot of modal errors.

-Wm