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


Groups > comp.lang.forth > #51381

Re: RfD Recognizer, 3rd version

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: RfD Recognizer, 3rd version
Date 2016-09-27 12:42 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2016Sep27.144207@mips.complang.tuwien.ac.at> (permalink)
References (1 earlier) <a6a3672d-2e36-4085-93bf-fbf4cc3a7d0e@googlegroups.com> <87oa3a6jn2.fsf@jester.gateway.pace.com> <7cf7cab7-4593-48e7-a088-218458d61003@googlegroups.com> <87fuol7ups.fsf@jester.gateway.pace.com> <b9qdnb_VYP2QrXfKnZ2dnUU7-TfNnZ2d@supernews.com>

Show all headers | View raw


Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> tabcomputing@gmail.com writes:
>>> Thanks, that helps. So it still goes word by word. But isn't that
>>> going to be rather slow? Every word has to run thru 1 to N functions
>>> to find a match, usually N. 
>> 
>> Usually 1.  The first thing is look up the word in the dictionary.  If
>> not, see if it's an integer literal, etc.  That's what the text
>> interpreter does now.
>
>I think the proposal is to allow recognizers to be run before
>dictionary search.

What is allowed does not mean that it usually happens.  The usual case
is that the recognizer for dictionary search is first, numbers second,
floats third, etc.  If you use the usual recognizers and the usual
order, you will run as many recognizers as you run now.

If you add a "->value" recognizer at the end, and have a lot of
occurences of "->value" in your code, you will see more recognizers
being tried, on average, than now.  I don't expect that to be a
performance issue, but if you really need to get the last drop of
performance out of text interpretation, you can reorder
non-conflicting recognizers (e.g., "->value" does not conflict with
the number recognizer for BASEs in the standard range) in the order
that produces the best performance (based on how often the recognizers
match and how fast they fail).

- 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

Re: RfD Recognizer, 3rd version trans <transfire@gmail.com> - 2016-09-26 20:33 -0700
  Re: RfD Recognizer, 3rd version Paul Rubin <no.email@nospam.invalid> - 2016-09-26 21:39 -0700
    Re: RfD Recognizer, 3rd version tabcomputing@gmail.com - 2016-09-26 22:45 -0700
      Re: RfD Recognizer, 3rd version Paul Rubin <no.email@nospam.invalid> - 2016-09-26 22:55 -0700
        Re: RfD Recognizer, 3rd version Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 03:38 -0500
          Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 12:42 +0000
          Re: RfD Recognizer, 3rd version Bernd Paysan <bernd@net2o.de> - 2016-09-27 13:23 +0000
          Re: RfD Recognizer, 3rd version trans <transfire@gmail.com> - 2016-09-27 19:09 -0700
            Re: RfD Recognizer, 3rd version JennyB <jennybrien@googlemail.com> - 2016-09-28 00:07 -0700
              Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-30 12:34 +0000
            Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 10:03 +0200
              Re: RfD Recognizer, 3rd version ruvim.pinka@gmail.com - 2016-09-28 02:39 -0700
                Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 13:22 +0200
            Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-28 11:41 +0000
      Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 15:15 +0200

csiph-web