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-15 10:43 +0000
Organization	Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID	<2017Jun15.124349@mips.complang.tuwien.ac.at> (permalink)
References	(6 earlier) <06GdnQ7u4dVFcKHEnZ2dnUU7-f_NnZ2d@supernews.com> <2017Jun11.125542@mips.complang.tuwien.ac.at> <dbGdnW6EQMvJ0qPEnZ2dnUU7-X_NnZ2d@supernews.com> <2017Jun13.172153@mips.complang.tuwien.ac.at> <4Y2dnc3jhr7uYN3EnZ2dnUU7-aXNnZ2d@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:
>>>> 
>>>> 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.  And no, Forth programs do not have to cope with all
kinds of implementation behaviour in the name of real-world
portability.  They can specify that their program is
standard-compliant, and leave it to the users of systems that do not
comply with the standard to switch to a standard-compliant system; and
if the non-compliant system claims to be standard, they can also
report a bug, and, as you once told me, they can also take it to the
courts.

But if you were right, and Forth programmers just had to deal with
whatever non-compliance the system implementors throw at them, why
would we need a standard?  Why are you on the committee.

>>>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.
>
>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@.

>> 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?

As for defining ticking and POSTPONEing locals, sure, if you think
that is needed, make a proposal.

I have not encountered a need to tick or POSTPONE locals and there is
a technical reason for that.  They are only valid inside a colon
definition.

So when doing normal programming, when you tick a local, you have to
EXECUTE it within the same colon definition; COMPILE,ing it makes no
sense (the result would be performed outside this colon definition);
likewise, POSTPONEing a local makes no sense.  For the
tick-and-execute case, one can construct cases that are not complete
nonsense, but it's hard to find one where if offers anything that
cannot be done just as easily in a different way.  E.g.

: foo {: a b :} ... if ['] a else ['] myconst then ... execute use ... ;

Writing

: foo {: a b :} ... if a else myconst then ... use ... ;

is shorter.  At the moment, I cannot find an example that would be
shorter with ticking.

Outside normal programming, when writing a compiler (and probably also
for other meta-programming tasks), it could be useful to generate an
anonymous local, and get a handle to it (e.g., the xt or nt), store it
in the compiler's symbol table, and use it when generating the code
for the rest of the definition.  But the current locals interface does
not give us that: (LOCAL) takes a name and produces a named local, and
you then have to refer to the local by name.  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.

>> 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.

>>>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.

- 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/

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