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

Groups > comp.lang.forth > #35474

Re: RFD Recognizer

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:
>>>Besides, if something is unnecessary...
>> 
>> Ex falso quodlibet.
>
>You will have to explain your reasoning in more detail if you want it
>to carry any weight.

Look who's talking.

>At present we have a fairly clean and simple
>interpreter loop, which (as has been noted here) a Forth programmer
>can write in Forth, and this is a basic entitlement.  All that is
>needed to implement recognizers is to replace the call to NUMBER or
>some equivalent with one to call recognizers, and we're done.  A
>simple Forth system needs only number conversion as its sole
>recognizer.
>
>This proposal, however, refactors the interpreter to use the
>recognizer stack for word lookup.  This is neither necessary nor IMO
>desirable.

I disagree about the cleanliness of the classic interpreter loop, and
it messes up the adjacent words (FIND and literal handling), too.  One
of the original motivations that finally resulted in the recognizer
idea was to clean up the literal handling mess, in particular dealing
with both single and double-cell numbers.

And if we can find a way to handle both literals and dictionary
lookups in a uniform way, that's cleaner than having a special case
for dictionary lookups.  Now with the design of the recognizers we
have found that way, and treating all of that in a uniform way is
certainly cleaner.

Apart from such design considerations, the practical advantage is to
allow to bypass the dictionary lookup part.  There are at least two
places in Gforth where that happens:

1) For the stuff skipped by [IF].

2) For the locals definition with { ... }.

Both these were implemented before we had recognizers using our
object-orineted wordlist mechanisms, in this case involving
"wordlists", that behave very differently from wordlists doing
dictionary lookups.  That's relatively complicated, and using
recognizers instead is more direct and probably simpler.

Concerning the usual patronizing argument "application programmers
should not do such things", that's as invalid as ever:

1) This is Forth.

2) Even application programmers that don't do that may want to use
   libraries written by system programmers.  To make such libraries
   portable, the standard should also support system programmers; an
   example is writing an interpreter loop, which you claim to be a
   basic entitlement.

>> : ]map   ]] 1 cells +loop [[ ; immediate
>> 
>> which is more readable than
>> 
>> : ]map 1 cells ]] literal +loop [[ ; immediate
>> 
>> (The former is admittedly a little bit slower on less sophisticated
>> compilers, but sophisticated compilers make it equally fast.)
>
>I think there must be some gap here in my understanding of what you're
>saying.  Is it that you can't write ]] ... [[ without postponeable
>numbers?

You can, as illustrated in the lower implementation of ]MAP.  But just
as we want to be able to put interrpeted code into a colon definition,
we also want to be able to put it inside ]] ... [[.  So we make NUMBER
complicated in order to be able to write "1" instead of "[ 1 ] literal"
in a colon definition, and likewise, we support recognizers in
postpone mode in order to write "1" instead of "[[ 1 ]] literal"
inside ]] ... [[.

>> Another Forth non-application is objects.fs.  There I needed to
>> POSTPONE "to this".  That is not directly possible
>
>Well, actually, it is, with EVALUATE, but you don't like that; but the
>fact you don't like it does not make it impossible.

You mean it is possible to replace postponeing "to this" with some
code involving EVALUATE.  The Wil Baden way to do it does not work
correctly in general, and for a general package like objects.fs that's
definitely not good enough.  And while I know how to do it correctly,
that way is long-winded and complex, and most Forth programmers
probably don't get it right.  Do you?

>> : to-this ( object -- ) \ objects- objects
>>    \g Set @code{this} (used internally, but useful when debugging).
>>    TO this ;
>> 
>> : enterm ( -- ; run-time: object -- )
>>    \g method prologue; @var{object} becomes new @code{this}.
>>    POSTPONE this
>>    POSTPONE >r
>>    POSTPONE to-this ;
>
>So the job is done, then.  Anything further is cuteness for its own
>sake.

Being able to write 2 SLOC instead of 6 SLOC for the same task is an
advantage, and not having to come up with an auxiliary definition to
work around artificial limitations of POSTPONE is also an advantage.

>> With a recognizer replacing TO, and that recognizer being
>> postponeable, there is no need for the TO-THIS workaround, and instead
>> one could directly write
>> 
>> : enterm ( -- ; run-time: object -- )
>>    \g method prologue; @var{object} becomes new @code{this}.
>>    ]] this >r ->this [[ ;
>
>Right now I don't see how this is an improvement.  In fact, this code
>is harder to follow and debug than the code above:

It is shorter and less littered with POSTPONE noise or helper words,
and therefore easier to follow once you know the notation.

>if I were trying to
>maintain this code I would immediately type
>
>  locate ->this
>
>and (presumably) the result would be
>
>  ->this ?

That depends on how LOCATE is implemented on the system, if at all.

It is relatively straightforward to make LOCATE use the recognizer
lookup mechanism and then point you to the definition of the ->
recognizer.  Then you can see that this recognizer accesses THIS, and
you can then LOCATE THIS.  Of course, it is likely that you know that
->THIS stores into THIS without having to lookup the recognizer, then
you can look THIS up directly.

Alternatively, LOCATE could also hook into dictionary lookup, so for a
recognizer that involves a dictionary lookup like the -> recognizer,
LOCATE would find THIS and show the source location of THIS.

Or LOCATE could show the source location of the recognizer and all the
words it looks up.

>and I would curse the devil who wrote it.

Instead, you could just ask your Forth implementor to support
recognizers in LOCATE.  I am sure they can come up with their own
ideas of how to do it well, but to save them the five minutes it took
me to come up with the ideas outlined above, you could forward the
ideas to them.

>  All you've succeeded in
>doing is burdening the reader with a pointless and obscure syntax for
>no good reason.  Code like this is an excellent argument against
>recognizers.

Your complaint is about ->THIS instead of TO THIS, but you agreed
earlier that getting rid of words like TO (and the STATE-smartness
etc. it entails) is a benefit of recognizers.  So there is a good
reason to do it.

And introducing anything new always puts a burden on the reader, but
in this case it is worth it.

- 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 2014: http://www.euroforth.org/ef14/

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

Thread

RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-02 11:56 -0800
  Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-03 05:37 -0600
    Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-03 12:56 +0000
      Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-04 04:23 -0600
        Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-04 11:25 +0000
          Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-05 04:43 -0600
            Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-05 12:35 +0000
              Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 10:33 -0600
                Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-07 15:29 +0000
                Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 12:57 -0600
                Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-07 12:27 -0800
                Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 00:42 +0100
                Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 20:55 +0000
    Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-03 06:43 -0800
      Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-03 07:54 -0800
        Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-03 08:37 -0800
          Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-03 10:08 -0800
        Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-04 12:15 +0000
          Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-09 10:15 -0800
            Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-09 12:11 -0800
              Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 22:46 +0100
      Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-04 04:37 -0600
        Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-04 06:32 -0800
          Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-05 04:55 -0600
            Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-05 10:06 -0800
      Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-04 16:02 +0000
        Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-04 11:06 -0800
          Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 08:18 -0800
            Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 08:59 -0800
            Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-05 10:23 -0800
              Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 15:36 +0000
                Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-08 10:54 -0800
                Re: RFD Recognizer Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 20:50 +0000
          Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 14:24 +0000
            Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-08 16:06 +0000
            Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 01:11 +0100
        Re: RFD Recognizer Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-05 17:19 +0100
    Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-03 16:08 +0100
    Re: RFD Recognizer hughaguilar96@gmail.com - 2015-01-03 16:05 -0800
      Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-04 04:42 -0600
      Re: RFD Recognizer stephen@mpeforth.com (Stephen Pelc) - 2015-01-06 18:01 +0000
    Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-04 15:11 +0000
      Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-05 05:00 -0600
        Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-05 13:39 +0000
          Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 04:57 -0600
            Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-06 18:00 +0000
              Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 05:13 -0600
                Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 17:18 +0000
                Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 13:04 -0600
  Re: RFD Recognizer Julian Fondren <julian.fondren@gmail.com> - 2015-01-04 07:48 -0800
    Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 06:01 -0800
      Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-05 14:31 +0000
        Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 08:43 -0800
          Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 15:22 +0000
        Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-06 02:48 +0100
          Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-06 03:13 +0000
    Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 13:45 +0000
  Re: RFD Recognizer Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 20:44 +0000
    Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-17 09:26 -0800
      Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 18:54 +0100
        Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-17 12:35 -0800
      Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-18 04:16 -0800
        Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-18 13:38 +0000
          Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-18 13:56 +0000
            Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-18 07:10 -0800
              Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-18 16:14 +0000
      Re: RFD Recognizer Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-20 18:26 +0000
        Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 23:54 +0100
          Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-21 09:05 -0800
            Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 20:50 +0100
            Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-22 10:55 +0000

csiph-web