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


Groups > comp.lang.forth > #13458

ANS' EVALUATE and related issues

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)

Show all headers | View raw


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 | NextNext in thread | Find similar


Thread

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