Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56948
| From | Alex <alex@rivadpm.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Recognizers & EVALUATE recursion |
| Date | 2017-04-09 22:37 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <oce9ce$rcs$1@dont-email.me> (permalink) |
| References | <oc85qd$t56$1@dont-email.me> <2017Apr8.161733@mips.complang.tuwien.ac.at> |
On 4/8/2017 15:17, Anton Ertl wrote: > Alex <alex@rivadpm.com> writes: >> Using EVALUATE or allowing an implicit use of EVALUATE in the >> execution path of a recognizer may cause problems. In my Forth >> (edited for clarity): >> >> : interpreter ( -- ) begin parse-name dup while default-recognize >> execute repeat 2drop ; >> >> : evaluate ( addr len -- ) ['] interpreter execute-parsing ; >> >> A recognizer using EVALUATE re-drives the interpreter, and hence >> the recognizer is potentially recursed into. >> >> Not every parse will cause issues, but there are certain >> pathological cases where the recogniser may infinitely recurse. In >> my case it was an EVALUATE for :NAME causing an EVALUATE for :NAME >> ... and so on. > > Recursion is just like loops: You have to make at least a little bit > of progress before recursing, or you will get an endless recursion > (at least with recursion that usually shows up as a return stack > overflow rather than just a hanging program). Yes. I documented this because it initially caught me by surprise, and stack overflow is pretty disastrous in outcome & difficult to debug in my system. It took a little while to realize that EVALUATE was the culprit. > > In general EVALUATE looks like a much too coarse tool for the > implementation of a recognizer: it can do many things out of your > control, based on stuff like STATE, BASE, the search order, and the > contents of the individual wordlists. They are known and in the user's control, since the evaluation is being done while the word is being recognized, not later. > A slightly less coarse approach is to call the recognizer stack again > (at least STATE should not influence that), but of course the issue > of requiring progress remains. The intent is to explore the feasibility of words of the form ([ ] is meta) w1:[w2[:w3]].p as object w1 [with public object w2 [etc]] supporting public symbol p. -- Alex
Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar | Unroll thread
Recognizers & EVALUATE recursion Alex <alex@rivadpm.com> - 2017-04-07 14:59 +0100
Re: Recognizers & EVALUATE recursion Matthias Trute <matthias.trute@gmail.com> - 2017-04-07 08:12 -0700
Re: Recognizers & EVALUATE recursion Alex <alex@rivadpm.com> - 2017-04-09 22:39 +0100
Re: Recognizers & EVALUATE recursion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-08 14:17 +0000
Re: Recognizers & EVALUATE recursion Alex <alex@rivadpm.com> - 2017-04-09 22:37 +0100
csiph-web