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


Groups > comp.lang.forth > #60608

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-11 10:55 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2017Jun11.125542@mips.complang.tuwien.ac.at> (permalink)
References (7 earlier) <hKydnVY_4s3asK3EnZ2dnUU7-WWdnZ2d@supernews.com> <ogpbsj$25a$1@dont-email.me> <4v2dnYUzuLdLgazEnZ2dnUU7-RfNnZ2d@supernews.com> <2017Jun10.182826@mips.complang.tuwien.ac.at> <06GdnQ7u4dVFcKHEnZ2dnUU7-f_NnZ2d@supernews.com>

Show all headers | View raw


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.

More generally, interpretation and compilation semantics, and
arbitrary combinations of them are part of the language standard.

Even more generally, we get these kinds of words from the requirement
that code can be cut-and-pasted between interpreted and compiled code.
Where does this requirement come from?  It's a property of a good part
of the language (normal words and numbers), so it's no wonder people
want to extend it to more or all of the language.  The question is if
we do it properly or if we cut corners and then get unintended
behaviour in corner cases.

>> And the result of obstructing anything (including improvements over
>> the present state) that's not in the direction of your Forth is
>> going to be a worse (even in your sense) and also less relevant
>> standard than we could otherwise achieve.
>
>Well, hold on: pointing out that there are simple solutions, and that
>the supposed problem is not a a failure of language design but a
>consequence of its misuse isn't being obstructive.

I am not sure what you are referring to.  Below you propose a
solution, but if you proposed this solution earlier in discussions on
this topic, I must have missed it.  And what do you mean with "its
misuse" in the present context?

Anyway, rare occurences of misuse are not a reason to adjust the
language design (at least for Forth; and hypothetical misuses should
be even less of a reason to reject recognizers), but in the case of
S"-like words they pop up so regularly, that we should come to grips
with their existence, and adjust our implementations to implement them
properly.  And for FIND that means to either accept the
state-dependent behaviour of Forth-94 (and it's coming from Chuck
Moore, after all) or replace it with FIND-NAME.

>> A remaining problem is [: ... ;], which a number of people want to use
>> interpretively, so [: is a word with non-default non-immediate
>> compilation semantics in Gforth.  I don't have a good idea how to fix
>> that, yet.
>
>Why not just say "no"?

Technically, we have solved the problem of implementing such words.
And as long as we have to implement S" etc., there is no reason to not
also have an interpretive "[:".

>Isn't the interpretive use of these words the
>same as :NONAME anyway?

Pretty much, yes.  There is some small difference, but I forget what
it was.  I think the main motivation is not this difference, but the
cut-n-paste requirement.  I think that several people have asked for
this interpretive behaviour of [: in the RfD phase of the quotations
proposal, supporting the view that many consider the cut-n-paste
requirement important (the shortness of [: ... ;] compared to :NONAME
... ; may also contribute).

>> Anyway, my point is that the complexity of non-default non-immediate
>> words is there because of requirements from some Forth users (enough
>> that all Forth systems have this crap in some form or other); we can
>> get rid of this complexity by providing alternative solutions, but we
>> do have to provide them.  We won't get rid of it by pretending that
>> these requirements don't exist.
>
>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.

A convention can be a solution to a technical problem, if it is
commonly accepted and followed.  In the present case, I don't see that
happening: No such words are specified in Forth-94 or Forth-2012, and
AFAICS neither SwiftForth, VFX, iForth nor Gforth documents such
words.  So while such a convention may in theory be able solve the
problem, in practice that has not happened yet.

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.

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.

- 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