Re: Another recognizer discussion

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Subject	Re: Another recognizer discussion
Newsgroups	comp.lang.forth
References	(7 earlier) <2017Jun11.125542@mips.complang.tuwien.ac.at> <dbGdnW6EQMvJ0qPEnZ2dnUU7-X_NnZ2d@supernews.com> <2017Jun13.172153@mips.complang.tuwien.ac.at> <4Y2dnc3jhr7uYN3EnZ2dnUU7-aXNnZ2d@supernews.com> <2017Jun15.124349@mips.complang.tuwien.ac.at>
Message-ID	<-emdnUDf3ME4CN_EnZ2dnUU7-WHNnZ2d@supernews.com> (permalink)
Date	2017-06-15 09:11 -0500

Show all headers | View raw

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 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:
>>>>> 
>>>>> 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.
>>
>>Exactly, and neither should we worry about whether such
>>implementations of S" are legal or not: they exist, and real-world
>>portable Forth programs have to cope with them.  So the argument:
>>
>>>>> 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.
>>
>>is moot.  Arguing that S" "cannot be implemented correctly..." is
>>pointless.  It can be implemented, and it is.
> 
> One can also implement OR to mean XOR, and it has actually been done.
> That does not make that implementation a correct standard-compliant
> implementation, and does not make the specification of OR in the
> standard moot.

That's hardly a similar situation.

> But if you were right, and Forth programmers just had to deal with
> whatever non-compliance the system implementors throw at them, 

I didn't say that.

> why would we need a standard?  Why are you on the committee.

>>> 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.
>>
>>I agree with all of that -- its logic is irrefutable -- but the
>>standard is already large, so I'm a bit more cautious than you about
>>the "should set an example" conclusion.
> 
> Ah, the word count issue.  There is an alternative: Make these words
> obsolescent.  Of course we need a replacement for this functionality,
> and we have one: For S" and S\", the string recognizer ("bla bla");
> for TO and IS, the TO-recognizer (->myvalue).  For ACTION-OF, I would
> just use a sequence involving DEFER@: instead of ACTION-OF FOO, have
> ['] FOO DEFER@.

Indeed.  To every problem there is a recognizer solution!

>>> I have certainly come across a case where I wanted to POSTPONE TO, and
>>> having [TO] available in that case would have been beneficial.
>>
>>Yes.  But from what I remember locals can be neither ticked or
>>POSTPONEd, so it's rather marginal unless that is fixed too.
> 
> What is rather marginal?

Why would you want to POSTPONE TO other than with a local?  TO's only
other use is for VALUEs, and there's scarcely a pressing need to use
VALUEs when metaprogramming.

> If you have to deal with name strings for locals anyway, there is no
> point in ticking or POSTPONing the local.  The way to go is to just
> EVALUATE the local when you want to compile a read from it, and to
> EVALUATE "TO <local>" when you want to compile a write to it (with
> appropriate precautions so that the right TO is seen).  Even with a
> handle, the TO-case cannot be done in the current standard setting,
> so if we want to cover that area, we would need to fix that, too.

Right, so my point is made, I think: I can't see much use for [TO] :
you might as well EVALUATE "to foo".

>>> 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).
>>
>>It's certainly a solution, but it would make little sense to propose a
>>bunch of words without the general principle being accepted.
> 
> It's unlikely that the bunch of words is accepted without the
> acceptance of the general principle, but in any case, it's a good
> idea to phrase your proposal as proposing the general principle, and
> these words as a consequence of that.  Of course, it's not clear if
> such a proposal will be accepted, but it will hopefully advance the
> discussion.

I wonder.  It seems to me that everyone has their own preferred
solution, and that they tend to stick to that solution.  Practice
diverges very widely.  I would like to know why simple compatible
solutions like this one haven't been accepted.

>>>>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.
>>
>>Sure, and I was like that when I was an inexperienced Forth programmer
>>too.  But I got over it when I discovered that the applications (and
>>the customers) were more interesting than futzing with the language
>>and the more trickery I wrote the longer it took to debug the
>>applications.
> 
> It seems that the experiences have diverged in this area.  I for one
> would have been happy with DEFER@, but a committee member (not an
> inexperienced programmer) insisted on adding ACTION-OF.

I would have though that the experience of lying on one's back inside
a machine while trying to debug a control system would be quite enough
to cure people of such regrettable tendencies, but evidently not.

Andrew.

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