Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #60701

Re: Another recognizer discussion

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: Another recognizer discussion
Date 2017-06-13 15:21 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2017Jun13.172153@mips.complang.tuwien.ac.at> (permalink)
References (6 earlier) <4v2dnYUzuLdLgazEnZ2dnUU7-RfNnZ2d@supernews.com> <2017Jun10.182826@mips.complang.tuwien.ac.at> <06GdnQ7u4dVFcKHEnZ2dnUU7-f_NnZ2d@supernews.com> <2017Jun11.125542@mips.complang.tuwien.ac.at> <dbGdnW6EQMvJ0qPEnZ2dnUU7-X_NnZ2d@supernews.com>

Show all headers | View raw

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> But sure, if we only had normal and immediate words, we could remove
>>>> the provision from the standard that the results of FIND may depend on
>>>> STATE.  Will you make a proposal for turning all words with
>>>> non-default compilation semantics (and all words with undefined
>>>> interpretation semantics) into either normal or immediate words?  Will
>>>> such a proposal actually find consensus?
>>>
>>>I don't expect that it would, so I won't, but the fact remains that
>>>the "problem" -- if there is one -- with XTs that makes them "too
>>>simple" is a property of some implementations, not of the language as
>>>such.
>> 
>> S" is not a property of some implementations, it's part of the
>> language standard.  It cannot be implemented correctly in a way that
>> FIND delivers the same xt in either state, unless we sacrifice the
>> requirement that FIND can be used to write a text interpreter.
>
>Maybe, but we've discussed that before, and It can be fixed by relaxing
>the specification of S" etc. to make it clear that a STATE-smart
>implementation is legal.  I do not believe the the original ANS TC
>intended to make STATE-smart implementations of S" illegal.

Yes, they probably wanted to allow such an implementation.  However,
in the 18 years between Forth-94 and 2012 nobody, not even those with
STATE-smart implementations of S" have proposed relaxing the
specification of S", plus a new word S\" was introduced that cannot be
implemented in a STATE-smart way while being compliant with the
specification, either.  So the implementors of STATE-smart systems are
apparently not interested very much in compliance in this area, so
maybe we should not be worrying about it, either.

>And I've
>not yet found an implementation of FIND that can't be used to write a
>text interpreter.

Yes, but in order to make that work, FIND is STATE-dependent in
Gforth.  If you want to tighten FIND so that it cannot produce a
state-dependent result, the result would be that user-defined text
interpreters would no longer work in Gforth.

>> And what do you mean with "its misuse" in the present context?
>
>STATE-smart words which can't be used as factors, such as S".  It's a
>violation of the "Don't bury your tools" principle.
[...]
>>>We already have a clean solution: every state-smart word should
>>>provide its components.  That's no more than a matter of good coding
>>>style.  So, for every state-smart FOO there is a (FOO) and a [FOO].
>> 
>> So your solution is to implement S" as STATE-smart word, adjust the
>> standard accordingly, and also provide (S") and [S"] as part of the
>> API?  And likewise for all the other words of this kind.
>
>It's not clear to me at this point whether we're discussing S" etc. or
>the use of STATE-smart words in application code.

First, the standard words, i.e., S" S\" TO IS ACTION-OF.  If the
solution is to provide the STATE-independent factors, the standard
should set an example and provide such factors for all these words.
There is nothing the standard can do about user-written code except
give a good example itself.

>If there's a need to use S" and TO as factors, then it would make good
>sense to do that, yes.  But that depends not on the general principle,
>but on whether anyone needs to use them as factors.  I certainly would
>not want to add more dead wood to the standard.

I have certainly come across a case where I wanted to POSTPONE TO, and
having [TO] available in that case would have been beneficial.

And if you think that the solution is to provide such factors with a
standard naming convention, then you should go ahead and propose
providing them.  The additional words cost very little in the
implementation (the functionality is there anyway).

And on the programmer side, it's easier when they are all available
instead of only some; even when it's not hard to work around the
absence of these words, as for IS (thanks to DEFER!), it's still
easier to directly use the factors when you want to POSTPONE and tick
such words, rather than working out how to program a workaround.

As for the all-important word count, you can see these additional
words as the cost of having such words, or as the cost of allowing
STATE-smart implementations.

>I have suggested clarifying the language which defines S" and TO in
>order to remove any doubt that STATE-smart versions of these words are
>legal.

TO, IS, and ACTION-OF already cannot be ticked or POSTPONEd.

>In the wider case, it makes sense for anyone contemplating writing a
>STATE-smart word to make its components available separately and to
>use a convention when naming them.  But their first thought should not
>be "How shall I write this STATE-smart word?" but "Should I write this
>STATE-smart word?"

Unfortunately, the answer of many has been "yes".  And they generally
have not provided the components, and certainly no naming convention
for these components has been established.

>> I suggested this solution in 1998 (in
>> <https://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf>,
>> section 4.1), and there have been enough discussions about
>> STATE-smartness and enough mentionings of this paper (at least 53 in
>> Usenet articles by me) that everybody concerned should have come
>> across it; so if they have not picked it up, it seems they did not
>> find it compelling enough.
>
>It seems obvious, and quite unremarkable.

And yet nobody does it.

>> But maybe I just did not present it well enough, and if you propose
>> changing the standard accordingly, we will find consensus that this is
>> the way to go.  But if we don't, it's not a general solution to the
>> problem.
>
>I don't think that this follows.  To the extent that the problem
>really exists, it's a solution that any programmer can use.  In what
>sense does a committee need to be involved?

You propose implementing S" S\" TO IS ACTION-OF as STATE-smart words,
and that the solution for ticking and POSTPONEing is to provide
STATE-independent components.  If the committee agrees with this
solution, then the committee should add the component words for these
words, both for direct use, and to set an example for other use.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:47 +0100
  Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:57 +0100
    Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-29 13:18 -0700
      Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 22:47 +0100
      Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:43 +0000
    Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:30 +0000
    Re: Another recognizer discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 09:53 +0200
    Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-30 22:02 +0100
      Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-31 01:27 -0700
        Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:12 +0100
      Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 03:43 -0700
        Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:03 +0100
        Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 16:46 +0000
      Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 11:28 +0000
        Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 12:17 +0000
        Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:10 +0100
          Re: Another recognizer discussion mhx@iae.nl - 2017-05-31 11:01 -0700
          Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-05-31 22:55 +0000
            Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:50 +0000
              Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 23:57 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 09:08 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-01 03:33 -0700
              Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-01 09:05 +0000
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 15:05 +0100
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 10:05 -0500
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 16:32 +0100
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-01 09:31 -0700
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 19:00 +0100
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 22:56 +0000
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-05 14:41 +0100
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:07 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 16:28 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:14 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-11 10:55 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-12 03:22 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:21 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-14 04:10 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 10:43 +0000
                Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-15 09:11 -0500
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 02:55 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-14 10:19 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 05:44 -0700
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 14:27 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 08:06 -0700
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 16:36 +0000
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 09:48 -0700
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 17:18 +0000
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 18:50 +0100
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 19:22 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-15 13:09 -0700
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:43 -0700
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-15 22:55 +0200
                Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 22:20 +0100
                pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 17:04 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 21:58 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 00:26 -0700
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) minforth@arcor.de - 2017-06-17 01:18 -0700
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 15:24 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 12:29 -0700
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:29 +0000
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-18 16:47 +0200
                Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 10:20 +0000
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:01 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:55 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 17:40 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:47 +0000
                Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 10:34 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 17:35 +0000
                Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-06-17 15:24 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:00 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 12:29 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 07:35 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 10:39 +0000
                Re: Another recognizer discussion Richard Owlett <rowlett@cloud85.net> - 2017-06-11 07:19 -0500
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 14:04 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 12:50 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 16:19 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 07:59 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 11:48 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 10:24 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 13:04 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 13:30 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 16:36 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 15:51 +0000
                Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 21:09 +0200
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 15:55 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 14:21 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 23:07 +0000
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 15:49 +0000
                Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 11:14 +0000
                Re: Another recognizer discussion minforth@arcor.de - 2017-06-11 08:24 -0700
                Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:07 +0000
            Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 12:11 +0100
  Re: Another recognizer discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-30 11:03 -0700

csiph-web