Re: RfD -- FVALUE vsn 2.0
- From: anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
- Date: Mon, 13 Apr 2009 17:41:17 GMT
stephenXXX@xxxxxxxxxxxx (Stephen Pelc) writes:
On Tue, 24 Mar 2009 13:52:25 GMT, anton@xxxxxxxxxxxxxxxxxxxxxxxxxx
(Anton Ertl) wrote:
But there are some non-standard things which he wants to be able to
do, such as
... to 1 2 myarray
Although I participate in the Forth200x process, I do not subscribe
to the view that the existing standard is necessarily good or perfect,
especially where notation is concerned. The restrictions on TO are one
of those cases.
Actually, I think the behavioural ideal for the non-parsing TO is the
simple variant that does everything at run-time. No STATE-smartness
or other complications.
Actually, thinking about this some more, I concluded that this is not
the behavioural ideal, at least not in this generality. We don't want
any forgotten TO to influence values that reside in completely
different places in source code. Consider the following
: compute-index ( -- u )
... some-value ... ;
: foo ... to compute-index my-array ... ;
The programmer probably intends the TO to affect MY-ARRAY, but the
non-parsing TO would affect SOME-VALUE. (Note that with source
inlining of COMPUTE-INDEX even an immediate TO with state-smart values
will probably not do the intended thing here).
For optimising compilers (now the majority in hosted systems),
the real issue is that Anton's proposition provides no notation
to solve the issue, which is how to specify the compilation
behaviour.
Which proposition do you have in mind? Concerning notation, Gforth
has notation for defining words that define combined words
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Combined-words.html>:
: def-word
create-interpret/compile
code1
interpretation>
code2
<interpretation
compilation>
code3
<compilation ;
E.g., one could define VALUE with a non-parsing TO like this:
variable toing toing off
: to toing on ; immediate
: value ( n "name" -- )
create-interpret/compile
,
interpretation> ( -- n | n -- )
toing @ if
! toing off
else
@
then
<interpretation
compilation> ( compilation. -- ; run-time. -- n )
POSTPONE literal toing @ if
POSTPONE ! toing off
else
POSTPONE @
then
<compilation ;
For compilers such as VFX which are capable of
optimising DOES> clauses, some magic needs to occur. In the
example below, INTERP> is a a version of DOES> to indicate that
only the interpretation action is being specified. SET-COMPILER
specifies the compiler of the last word defined, in this case,
that of the child of VALUE. VALCOMP and VALINTERP are the
crequired compilation and interpretation factors.
: value \ x -- ; -- x
create
, ['] valComp set-compiler
interp>
valInterp
;
Ok. I don't think that we need to define defining words that define
combined words in portable code, so we do not need to standardize the
notation.
But then Stephen
does not want to solve this problem (as demonstrated by using an
immediate TO, which behaves differently from the non-immediate TO in
this case, too). And he probably wants to provide some compile-time
error checking. So one has to find a different specification for what
he wants, and then one can think about how to implement it efficiently
*and* correctly. It's a mess. I'm happy that I use a parsing TO.
Speak for yourself. If you want to know what I personally think, you
only have to ask. If you want to know MPE's position, ask. What you
have done is to state a position. What you have not done is to state
a generally acceptable notational solution.
I'm sorry that I brainstormed publically about how to solve a problem
of your system, but I cannot promise that it won't happen again.
- 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 2009: http://www.euroforth.org/ef09/
.
- Prev by Date: Re: FILE-SOURCE etc. and INTERPET-WITH
- Next by Date: Re: Blocks (was: FILE-SOURCE etc. and INTERPET-WITH)
- Previous by thread: Re: RfD -- FVALUE vsn 2.0
- Next by thread: Re: RfD -- FVALUE vsn 2.0
- Index(es):
Relevant Pages
|
