Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #13458
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | ANS' EVALUATE and related issues |
| Date | 2012-07-02 19:46 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jstbq0$l4f$1@speranza.aioe.org> (permalink) |
6.1.1360 EVALUATE "[...] Make the string described by 'c-addr' and 'u' both the input source and input buffer, [...] " Does that mean I can CMOVE the EVALUATE string to TIB? Or, must the original string in it's original location be parsed? It says to make the string *described* by ... It doesn't say the original string, in the original location, must be used or parsed in place. Is that an acceptable interpretation? Or, am I placing emphasis where it's not present? What is the intent here? I.e., is it legitimate to copy the original string to another buffer and process that secondary buffer? That's what I did, copying it to TIB . That works - via INTERPRET calling WORD. Basically, the EOL of the prior input is not detected when "0 >IN !" is set by EVALUATE. So, INTERPRET continues parsing instead of return to QUIT when EVALUATE is executed. Is using PAD as the secondary buffer acceptable too? 3.3.3.5 Input Buffers "[...] A program shall not write into the input buffer. [...]" Is EVALUATE considered to be a program? (No.) EVALUATE is implemented as a colon definition and so are programs in Forth... Well, I'm assuming that's a "no" - as in a program being user code and not system code. Otherwise, the distinction is very blurred in Forth as compared to other languages as to what constitutes a program. 3.3.3.5 Input Buffers "[...] or a buffer specified by EVALUATE. In all cases, SOURCE returns the beginning address and length in characters of the current input buffer." Does that mean something must also set #TIB when EVALUATE is used? What about setting SPAN ? The statement _only_ says SOURCE must work and not necessarily SPAN or #TIB ... Setting either isn't specified in the description for EVALUATE or ACCEPT either. My SOURCE returns TIB and #TIB. My EXPECT sets SPAN. QUERY sets #TIB from SPAN (reworked recently for SPAN instead of #TIB). Should my ACCEPT also set #TIB ? I.e., in order to be consistent, or to just have #TIB set? Or, should SOURCE be rewritten to return TIB and SPAN ? If so, should #TIB be _only_ set for QUERY then? My WORD is TIB based. So, rewriting SOURCE to return a non-TIB buffer not something I'm looking at currently. But, I'm interested in knowing if it could become a future issue. 6.2.2125 REFILL "[...] When the input source is a string from EVALUATE, return 'false' and perform no other action." If due to the implementation of EVALUATE , REFILL can never receive an input source string from EVALUATE ... ? (Ignoring that...) A.6.2.2040 QUERY "The function QUERY may be performed with ACCEPT and EVALUATE." If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based), should I rewrite QUERY to use ACCEPT and EVALUATE ? They both currently use TIB too ... It seems, at least from my definitions, that QUERY was broken into ACCEPT and EVALUATE, and reworked for a generic buffer. The issue I have - which really isn't a problem yet - is that ACCEPT and EVALUATE can use _any_ buffer. However, the remainder of my parsing words are all TIB based, some explicitly so, like WORD . The TIB based design required my EVALUATE to copy into TIB instead of using a generic buffer. I'm not currently "seeing" a problem with doing this, although I just implemented it. I think maybe at the 'heart' of the issue of using ACCEPT and EVALUATE is what exactly is setting the "input buffer" address for SOURCE to return: ACCEPT? EXPECT? EVALUATE? ... Without something saving the address, I can't foresee WORD being rewritten as non-TIB based. I do not have PARSE and REFILL yet. But, PARSE seems to be a modified WORD and REFILL seems to be a modified version of QUERY. That's where I'll start with them, anyway. REFILL supporting multiple input source probably won't be supported, at least right away, since my Forth only supports terminal input - although I've modified it for minimal file input. That's not exactly Forth compliant though, yet. Rod Pemberton
Back to comp.lang.forth | Previous | Next — Next in thread | Find similar
ANS' EVALUATE and related issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-02 19:46 -0400
Re: ANS' EVALUATE and related issues BruceMcF <agila61@netscape.net> - 2012-07-02 17:01 -0700
Re: ANS' EVALUATE and related issues Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-03 15:00 +0000
Re: ANS' EVALUATE and related issues anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-03 15:33 +0000
Re: ANS' EVALUATE and related issues Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-03 02:54 -0500
Re: ANS' EVALUATE and related issues Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-03 03:32 -0500
Re: ANS' EVALUATE and related issues Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-03 03:53 -0700
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-03 08:50 -1000
Re: ANS' EVALUATE and related issues Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-03 03:47 -0700
Re: ANS' EVALUATE and related issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-04 05:14 -0400
Re: ANS' EVALUATE and related issues Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-04 04:10 -0700
Re: ANS' EVALUATE and related issues Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-04 06:34 -0500
Re: ANS' EVALUATE and related issues Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-04 05:22 -0700
Re: ANS' EVALUATE and related issues Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-05 04:08 +0000
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-04 18:32 -1000
Re: ANS' EVALUATE and related issues Alex McDonald <blog@rivadpm.com> - 2012-07-05 05:25 -0700
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-05 08:04 -1000
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-04 08:02 -1000
Re: ANS' EVALUATE and related issues Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-05 03:58 +0000
Re: ANS' EVALUATE and related issues anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-03 10:22 +0000
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-03 09:19 -1000
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-03 09:35 -1000
Re: ANS' EVALUATE and related issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-04 05:12 -0400
Re: ANS' EVALUATE and related issues Coos Haak <chforth@hccnet.nl> - 2012-07-04 17:53 +0200
Re: ANS' EVALUATE and related issues BruceMcF <agila61@netscape.net> - 2012-07-04 08:53 -0700
Re: ANS' EVALUATE and related issues "Elizabeth D. Rather" <erather@forth.com> - 2012-07-04 08:10 -1000
Re: ANS' EVALUATE and related issues BruceMcF <agila61@netscape.net> - 2012-07-03 16:09 -0700
csiph-web