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

Groups > comp.lang.forth > #54549

Re: Recognizers

Show all headers | View raw

Alex <alex@rivadpm.com> writes:
>On 1/23/2017 13:30, Alex wrote:
>> On 1/22/2017 01:42, Alex wrote:
>>> Some recognizer observations.
>>
>> Refer to http://amforth.sourceforge.net/pr/Recognizer-rfc-C.html
>>
>
>6. Search order, wordlists and FIND-NAME
>
>The maintenance of two search orders is problematic

Yes, combining the recognizer and wordlist search order looks
attractive, but the problem is existing uses of SET-ORDER ONLY etc.
If the programmer has written, say

forth-wordlist 1 set-order

should SET-ORDER add the integer recognizer, or integer and FP
recognizers or more recognizers?  Likewise, GET-ORDER should not
return the default recognizers, but would return any additional
recognizers.  With the recognizer order as separate entity, SET-ORDER
does not affect the active recognizers, and GET-ORDER does not see
them.

>http://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/ertl-recognizers.pdf 
>recommends
>
>"While hooking into find has some advantages, the advantages of hooking 
>into the text interpreter, in particular with respect to backwards 
>compatibility, outweigh them."

Hooking into FIND seemed like the logical thing to do for my
"temporary word" approach: FIND would then return the xt of the
temporary word, and FIND-NAME the nt.  For the current, more practical
proposal, hooking into FIND cannot work, because the additional data
is passed on the stack, so the stack effect would be wrong (and
stashing the data in some fixed buffer does not cut it, either).

But even for the "temporary word" approach, hooking it into FIND is
not a good idea, as pointed out by Bernd Paysan: FIND is used in
existing user-defined interpreters, and these may not be prepared to
have additional recognizers active.

>I'm not so sure; phrases like
>
>get-recognizers ’ single-recognizer -rot 1+ set-recognizers
>
>are not paricularly clear without some form of explanation. Support 
>words would be useful.

The idea here is probably that GET-ORDER and SET-ORDER are standard
already, and to provide an interface that parallels this interface.
As for convenience words, not even >ORDER has been proposed, and I
expect changes to the search order to be more frequent than changes to
the recognizer order.

That being said, maybe GET-ORDER/SET-ORDER is not so good that we
should make it the model for further interfaces.

Lately I lean towards an interface where we can construct a recognizer
as a sequence of other recognizers in the dictionary, e.g., as follows:

\ we have a recognizer STANDARD-RECOGNIZERS

rec-seq my-recognizers
' standard-recognizers ,
' angle-recognizer ,
end-seq

' my-recognizers is forth-recognizer
... do something with angles ...
' standard-recognizers is forth-recognizer

>7. FORTH-RECOGNIZER
>
>Having this as a value to allow multiple recognizer stacks is debatable. 
>We don't have a way of specifying multiple search order stacks.

With the GET/SET interface, we don't need that, true.  With an
interface like the one above, we would need it.

>The whole area of search orders and recognizer stacks is much messier 
>than I think it need be. A uniform stack & some way of managing it is 
>imho required, but it might make the proposal a larger and more 
>fundamental change than the community is willing to support.

I don't think it's particularly messy.  It's just that there are a
buch of options, each with something to be said for them.  If we want
to think them all through and find the best one, you end up in a mess.
But given that there has been no strong movement to replace
GET-ORDER/SET-ORDER with something more convenient, maybe a suboptimal
solution is not a big problem.  So let's just go with the one that the
proponent decides on.

- 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 2016: http://www.euroforth.org/ef16/

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

Thread

Recognizers Alex <alex@rivadpm.com> - 2017-01-22 01:42 -0500
  Re: Recognizers Matthias Trute <matthias.trute@gmail.com> - 2017-01-22 03:06 -0800
  Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 14:42 +0000
    Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-22 17:26 -0500
    Re: Recognizers Bernd Paysan <bernd@net2o.de> - 2017-01-24 00:57 +0000
      Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-24 16:23 +0000
        Re: Recognizers Bernd Paysan <bernd@net2o.de> - 2017-01-24 21:47 +0000
  Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 08:30 -0500
    Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 08:57 -0500
    Re: Recognizers Matthias Trute <matthias.trute@gmail.com> - 2017-01-23 10:58 -0800
      Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 14:45 -0500
      Re: Recognizers JennyB <jennybrien@googlemail.com> - 2017-01-27 15:05 -0800
    Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-29 22:54 +0000
      Re: Recognizers JennyB <jennybrien@googlemail.com> - 2017-01-30 09:11 -0800
      Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-30 16:34 +0000
  Re: Recognizers Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-31 21:03 +0000
    Re: Recognizers albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-01 12:37 +0100

csiph-web