However, this doesn't work for copying IMMEDIATE words. I can use
EVALUATE, but it's very wordy:
: & ( <w> -- )
S" : " PAD PLACE BL WORD DUP >R COUNT 2DUP PAD APPEND
S" " PAD APPEND
R> FIND NIP DUP IF 1 =
IF S" POSTPONE " PAD APPEND PAD APPEND
S" ; IMMEDIATE" PAD APPEND \ : FOO POSTPONE FOO ;
IMMEDIATE
ELSE PAD APPEND S" ;" PAD APPEND \ : FOO FOO ;
THEN
PAD COUNT EVALUATE
ELSE 3DROP THEN \ Not found, don't make an
alias
;
Is there a simpler (but portable) way? Does 200x propose ALIAS?
> >Is there a simpler (but portable) way? Does 200x propose ALIAS?
> SYNONYM <newname> <oldname>
> Stephen
> --
> Stephen Pelc, stephen...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads
I thought Synonym would only create a synonym. It doesn't copy the
original code into a new word.
The OP wants to duplicate a word from one wordlist into another. Not
quite the same as SYNONYM.
Nevertheless, that raises an interesting point in itself; One might
consider, rather than just blindly copying the executable code into
the new word, compiling a call to the original word instead. It saves
space on constrained systems.
On Wed, 8 Feb 2012 02:31:06 -0800 (PST), Mark Wills
<markrobertwi...@yahoo.co.uk> wrote:
>> >Is there a simpler (but portable) way? Does 200x propose ALIAS?
>> SYNONYM <newname> <oldname>
>I thought Synonym would only create a synonym. It doesn't copy the
>original code into a new word.
>The OP wants to duplicate a word from one wordlist into another. Not
>quite the same as SYNONYM.
What Brad's code does is to generate a new word of the form
: foo foo ;
which is not the same as copying the binary. Copying the binary is
actually quite hard to do on some implementations and CPUs.
Stephen
-- Stephen Pelc, stephen...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
> > >Is there a simpler (but portable) way? Does 200x propose ALIAS?
> > SYNONYM <newname> <oldname>
> > Stephen
> > --
> > Stephen Pelc, stephen...@mpeforth.com
> > MicroProcessor Engineering Ltd - More Real, Less Time
> > 133 Hill Lane, Southampton SO15 5AF, England
> > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> > web:http://www.mpeforth.com-free VFX Forth downloads
> I thought Synonym would only create a synonym. It doesn't copy the
> original code into a new word.
> The OP wants to duplicate a word from one wordlist into another. Not
> quite the same as SYNONYM.
> Nevertheless, that raises an interesting point in itself; One might
> consider, rather than just blindly copying the executable code into
> the new word, compiling a call to the original word instead. It saves
> space on constrained systems.
Then (assuming you have VOCABULARY, and this can obviously be extended
to wordlists);
> On Wed, 8 Feb 2012 02:31:06 -0800 (PST), Mark Wills
> <markrobertwi...@yahoo.co.uk> wrote:
>>>> Is there a simpler (but portable) way? Does 200x propose ALIAS?
>>> SYNONYM<newname> <oldname>
>> I thought Synonym would only create a synonym. It doesn't copy the
>> original code into a new word.
>> The OP wants to duplicate a word from one wordlist into another. Not
>> quite the same as SYNONYM.
> What Brad's code does is to generate a new word of the form
> : foo foo ;
> which is not the same as copying the binary. Copying the binary is
> actually quite hard to do on some implementations and CPUs.
And why would one actually want to do that?
Cheers,
Elizabeth
-- ==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
> > > >Is there a simpler (but portable) way? Does 200x propose ALIAS?
> > > SYNONYM <newname> <oldname>
> > > Stephen
> > > --
> > > Stephen Pelc, stephen...@mpeforth.com
> > > MicroProcessor Engineering Ltd - More Real, Less Time
> > > 133 Hill Lane, Southampton SO15 5AF, England
> > > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> > > web:http://www.mpeforth.com-freeVFX Forth downloads
> > I thought Synonym would only create a synonym. It doesn't copy the
> > original code into a new word.
> > The OP wants to duplicate a word from one wordlist into another. Not
> > quite the same as SYNONYM.
> > Nevertheless, that raises an interesting point in itself; One might
> > consider, rather than just blindly copying the executable code into
> > the new word, compiling a call to the original word instead. It saves
> > space on constrained systems.
> Then (assuming you have VOCABULARY, and this can obviously be extended
> to wordlists);
> : OLDNAME .... ;
> VOCABULARY NEWVOC
> ALSO NEWVOC DEFINITIONS
> SYNONYM NEWNAME OLDNAME
> PREVIOUS DEFINITIONS
That does not, however, import the word under the same name as "&" is
trying to do. DEFER and IS would do so, I think, by reusing the word
in the input buffer. But if the extra semantics of DEFER and IS are
not required, the does-@EXECUTE approach would be about as compact:
: does-@EXECUTE DOES> @ EXECUTE ;
: & ( "name" -- )
>IN @ BL WORD FIND ?DUP IF
ROT >IN ! SWAP CREATE , does-@EXECUTE
1 = IF IMMEDIATE THEN
ELSE CR COUNT TYPE SPACE ." ???" THEN ;
: & ( "name" -- )
>IN @ BL WORD FIND ?DUP IF
ROT DUP >IN ! DEFER
>IN ! SWAP ['] IS EXECUTE
1 = IF IMMEDIATE THEN
ELSE CR COUNT TYPE SPACE ." ???" THEN ;
> > On Wed, 8 Feb 2012 02:31:06 -0800 (PST), Mark Wills
> > <markrobertwi...@yahoo.co.uk> wrote:
> >>>> Is there a simpler (but portable) way? Does 200x propose ALIAS?
> >>> SYNONYM<newname> <oldname>
> >> I thought Synonym would only create a synonym. It doesn't copy the
> >> original code into a new word.
> >> The OP wants to duplicate a word from one wordlist into another. Not
> >> quite the same as SYNONYM.
> > What Brad's code does is to generate a new word of the form
> > : foo foo ;
> > which is not the same as copying the binary. Copying the binary is
> > actually quite hard to do on some implementations and CPUs.
> And why would one actually want to do that?
Inlining, dynamic loading (particularly of libraries), "sandpit"
debugging, virtualisation, compilation out of line or off-processor,
and so on. The usual technique is to either keep a static set of
relocations that are applied when the code is loaded or moved; or
dynamically generate them by disassembling the code. It's usually
required for processors that utilise position dependent code.
Many of these may not apply to Forth, although inlining is an
exception.
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
On Wed, 08 Feb 2012 07:11:34 -1000, "Elizabeth D. Rather"
<erat...@forth.com> wrote:
>> What Brad's code does is to generate a new word of the form
>> : foo foo ;
>> which is not the same as copying the binary. Copying the binary is
>> actually quite hard to do on some implementations and CPUs.
>And why would one actually want to do that?
1) : foo foo ;
That's sometimes useful to expose words. Clients do it.
2) Binary copy
Some code generators (e.g. SwiftForth) do/did this.
Stephen
-- Stephen Pelc, stephen...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
> On Feb 8, 5:11 pm, "Elizabeth D. Rather"<erat...@forth.com> wrote:
>> On 2/8/12 1:19 AM, Stephen Pelc wrote:
...
>>> What Brad's code does is to generate a new word of the form
>>> : foo foo ;
>>> which is not the same as copying the binary. Copying the binary is
>>> actually quite hard to do on some implementations and CPUs.
>> And why would one actually want to do that?
> Inlining, dynamic loading (particularly of libraries), "sandpit"
> debugging, virtualisation, compilation out of line or off-processor,
> and so on. The usual technique is to either keep a static set of
> relocations that are applied when the code is loaded or moved; or
> dynamically generate them by disassembling the code. It's usually
> required for processors that utilise position dependent code.
> Many of these may not apply to Forth, although inlining is an
> exception.
Ok, but my understanding of the OP was that he wanted to access the word from a different wordlist. Stephen's SYNONYM does that nicely. Inlining is a compiler strategy in itself, not particularly related to getting something visible in a different wordlist. If wordlist visibility is the issue, I don't see why copying the code itself is relevant.
Cheers,
Elizabeth
-- ==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
> > > > >Is there a simpler (but portable) way? Does 200x propose ALIAS?
> > > > SYNONYM <newname> <oldname>
> > > > Stephen
> > > > --
> > > > Stephen Pelc, stephen...@mpeforth.com
> > > > MicroProcessor Engineering Ltd - More Real, Less Time
> > > > 133 Hill Lane, Southampton SO15 5AF, England
> > > > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> > > > web:http://www.mpeforth.com-freeVFXForth downloads
> > > I thought Synonym would only create a synonym. It doesn't copy the
> > > original code into a new word.
> > > The OP wants to duplicate a word from one wordlist into another. Not
> > > quite the same as SYNONYM.
> > > Nevertheless, that raises an interesting point in itself; One might
> > > consider, rather than just blindly copying the executable code into
> > > the new word, compiling a call to the original word instead. It saves
> > > space on constrained systems.
> > Then (assuming you have VOCABULARY, and this can obviously be extended
> > to wordlists);
> > : OLDNAME .... ;
> > VOCABULARY NEWVOC
> > ALSO NEWVOC DEFINITIONS
> > SYNONYM NEWNAME OLDNAME
> > PREVIOUS DEFINITIONS
> That does not, however, import the word under the same name as "&" is
> trying to do. DEFER and IS would do so, I think, by reusing the word
> in the input buffer. But if the extra semantics of DEFER and IS are
> not required, the does-@EXECUTE approach would be about as compact:
> : does-@EXECUTE DOES> @ EXECUTE ;
> : & ( "name" -- )
> >IN @ BL WORD FIND ?DUP IF
> ROT >IN ! SWAP CREATE , does-@EXECUTE
> 1 = IF IMMEDIATE THEN
> ELSE CR COUNT TYPE SPACE ." ???" THEN ;
> : & ( "name" -- )
> >IN @ BL WORD FIND ?DUP IF
> ROT DUP >IN ! DEFER
> >IN ! SWAP ['] IS EXECUTE
> 1 = IF IMMEDIATE THEN
> ELSE CR COUNT TYPE SPACE ." ???" THEN ;
SYNONYM allows both names to be the same. Any system that declares and
finds the new THISNAME as its own alias is in error.
15.6.2. SYNONYM TOOLS EXT
For both strings skip leading space delimiters. Parse newname and
oldname delimited by a space. Create a definition for newname with the
semantics defined below. Newname may be the same as oldname; when
looking up oldname, newname shall not be found .
> On Feb 8, 5:19 pm, Alex McDonald<b...@rivadpm.com> wrote:
>> SYNONYM allows both names to be the same. Any system that declares and
>> finds the new THISNAME as its own alias is in error.
> Is the SYNONYM of an immediate word defined to be immediate?
I think not automatically. You would have to mark your synonym as immediate. It can conceivably be useful to define a non-immediate synonym of an immediate word.
Cheers,
Elizabeth
-- ==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
On Feb 9, 6:55 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 2/8/12 1:05 PM, BruceMcF wrote:
> > On Feb 8, 5:19 pm, Alex McDonald<b...@rivadpm.com> wrote:
> >> SYNONYM allows both names to be the same. Any system that declares and
> >> finds the new THISNAME as its own alias is in error.
> > Is the SYNONYM of an immediate word defined to be immediate?
> I think not automatically. You would have to mark your synonym as
> immediate. It can conceivably be useful to define a non-immediate
> synonym of an immediate word.
According to the spec it's not portable. In the case of my Forth, the
word can be marked immediate because the old word's definition is
copied to newname. I can envisage dictionaries where the
implementation has names and pointers to header structures; in which
case, a shared header structure would result in also marking oldname
as immediate.
15.6.2. SYNONYM TOOLS EXT
( “<spaces>newname” “<spaces>oldname” -- ) X:synonym
For both strings skip leading space delimiters. Parse newname and
oldname delimited by a space. Create a definition for newname with the
semantics defined below. Newname may be the same as oldname; when
looking up oldname, newname shall not be found.
An ambiguous conditions exists if oldname can not be found or
IMMEDIATE is applied to newname.
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
On Feb 9, 1:55 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> > Is the SYNONYM of an immediate word defined to be immediate?
> I think not automatically. You would have to mark your synonym as
> immediate. It can conceivably be useful to define a non-immediate
> synonym of an immediate word.
Then for the target application, where the desire is for the immediacy
or not to be inherited, it wouldn't seem like much less trouble than
the BL WORD FIND approach.
> On Feb 9, 6:55 pm, "Elizabeth D. Rather"<erat...@forth.com> wrote:
>> On 2/8/12 1:05 PM, BruceMcF wrote:
>>> On Feb 8, 5:19 pm, Alex McDonald<b...@rivadpm.com> wrote:
>>>> SYNONYM allows both names to be the same. Any system that declares and
>>>> finds the new THISNAME as its own alias is in error.
>>> Is the SYNONYM of an immediate word defined to be immediate?
>> I think not automatically. You would have to mark your synonym as
>> immediate. It can conceivably be useful to define a non-immediate
>> synonym of an immediate word.
> According to the spec it's not portable. In the case of my Forth, the
> word can be marked immediate because the old word's definition is
> copied to newname. I can envisage dictionaries where the
> implementation has names and pointers to header structures; in which
> case, a shared header structure would result in also marking oldname
> as immediate.
> 15.6.2. SYNONYM TOOLS EXT
> ( “<spaces>newname” “<spaces>oldname” -- ) X:synonym
> For both strings skip leading space delimiters. Parse newname and
> oldname delimited by a space. Create a definition for newname with the
> semantics defined below. Newname may be the same as oldname; when
> looking up oldname, newname shall not be found.
> An ambiguous conditions exists if oldname can not be found or
> IMMEDIATE is applied to newname.
<quote>
newname interpretation: ( i*x -- j*x )
Perform the interpretation semantics of oldname.
newname compilation: ( i*x -- j*x )
Perform the compilation semantics of oldname.
</quote>
If oldname is immediate and an implementation doesn't make newname immediate then their compilation semantics are different which violates the second statement above.
Therefore ISTM that immediacy must be inherited and the answer to Bruce's original question is yes.
> > On Feb 9, 6:55 pm, "Elizabeth D. Rather"<erat...@forth.com> wrote:
> >> On 2/8/12 1:05 PM, BruceMcF wrote:
> >>> On Feb 8, 5:19 pm, Alex McDonald<b...@rivadpm.com> wrote:
> >>>> SYNONYM allows both names to be the same. Any system that declares and
> >>>> finds the new THISNAME as its own alias is in error.
> >>> Is the SYNONYM of an immediate word defined to be immediate?
> I think so, see below.
> >> I think not automatically. You would have to mark your synonym as
> >> immediate. It can conceivably be useful to define a non-immediate
> >> synonym of an immediate word.
> > According to the spec it's not portable. In the case of my Forth, the
> > word can be marked immediate because the old word's definition is
> > copied to newname. I can envisage dictionaries where the
> > implementation has names and pointers to header structures; in which
> > case, a shared header structure would result in also marking oldname
> > as immediate.
> > 15.6.2. SYNONYM TOOLS EXT
> > ( “<spaces>newname” “<spaces>oldname” -- ) X:synonym
> > For both strings skip leading space delimiters. Parse newname and
> > oldname delimited by a space. Create a definition for newname with the
> > semantics defined below. Newname may be the same as oldname; when
> > looking up oldname, newname shall not be found.
> > An ambiguous conditions exists if oldname can not be found or
> > IMMEDIATE is applied to newname.
> <quote>
> newname interpretation: ( i*x -- j*x )
> Perform the interpretation semantics of oldname.
> newname compilation: ( i*x -- j*x )
> Perform the compilation semantics of oldname.
> </quote>
> If oldname is immediate and an implementation doesn't make newname
> immediate then their compilation semantics are different which violates
> the second statement above.
> Therefore ISTM that immediacy must be inherited and the answer to
> Bruce's original question is yes.
> --
> Gerry
Elizabeth was suggesting immediacy can be set on newname when oldname
is not immediate, which is ambiguous;
BruceMcF <agil...@netscape.net> writes:
>On Feb 8, 5:19=A0pm, Alex McDonald <b...@rivadpm.com> wrote:
>> SYNONYM allows both names to be the same. Any system that declares and
>> finds the new THISNAME as its own alias is in error.
>Is the SYNONYM of an immediate word defined to be immediate?
> On Feb 10, 9:32 am, Gerry Jackson<ge...@jackson9000.fsnet.co.uk>
> wrote:
>> On 09/02/2012 21:36, Alex McDonald wrote:
>>> On Feb 9, 6:55 pm, "Elizabeth D. Rather"<erat...@forth.com> wrote:
>>>> On 2/8/12 1:05 PM, BruceMcF wrote:
>>>>> On Feb 8, 5:19 pm, Alex McDonald<b...@rivadpm.com> wrote:
>>>>>> SYNONYM allows both names to be the same. Any system that declares and
>>>>>> finds the new THISNAME as its own alias is in error.
>>>>> Is the SYNONYM of an immediate word defined to be immediate?
>> I think so, see below.
>>>> I think not automatically. You would have to mark your synonym as
>>>> immediate. It can conceivably be useful to define a non-immediate
>>>> synonym of an immediate word.
>>> According to the spec it's not portable. In the case of my Forth, the
>>> word can be marked immediate because the old word's definition is
>>> copied to newname. I can envisage dictionaries where the
>>> implementation has names and pointers to header structures; in which
>>> case, a shared header structure would result in also marking oldname
>>> as immediate.
>>> 15.6.2. SYNONYM TOOLS EXT
>>> ( “<spaces>newname” “<spaces>oldname” -- ) X:synonym
>>> For both strings skip leading space delimiters. Parse newname and
>>> oldname delimited by a space. Create a definition for newname with the
>>> semantics defined below. Newname may be the same as oldname; when
>>> looking up oldname, newname shall not be found.
>>> An ambiguous conditions exists if oldname can not be found or
>>> IMMEDIATE is applied to newname.
>> <quote>
>> newname interpretation: ( i*x -- j*x )
>> Perform the interpretation semantics of oldname.
>> newname compilation: ( i*x -- j*x )
>> Perform the compilation semantics of oldname.
>> </quote>
>> If oldname is immediate and an implementation doesn't make newname
>> immediate then their compilation semantics are different which violates
>> the second statement above.
>> Therefore ISTM that immediacy must be inherited and the answer to
>> Bruce's original question is yes.
>> --
>> Gerry
> Elizabeth was suggesting immediacy can be set on newname when oldname
> is not immediate,
Not the way I read it, she was referring to an immediate oldname and attempting to make newname match it by use of immediate ...
> which is ambiguous;
Correct
> : foo ;
> synonym bar foo immediate
> This is ok;
> : foo ; immediate
> synonym bar foo
Yes and bar is automatically immediate (or should be).
> > On Feb 10, 9:32 am, Gerry Jackson<ge...@jackson9000.fsnet.co.uk>
> > wrote:
> >> On 09/02/2012 21:36, Alex McDonald wrote:
> >>> On Feb 9, 6:55 pm, "Elizabeth D. Rather"<erat...@forth.com> wrote:
> >>>> On 2/8/12 1:05 PM, BruceMcF wrote:
> >>>>> On Feb 8, 5:19 pm, Alex McDonald<b...@rivadpm.com> wrote:
> >>>>>> SYNONYM allows both names to be the same. Any system that declares and
> >>>>>> finds the new THISNAME as its own alias is in error.
> >>>>> Is the SYNONYM of an immediate word defined to be immediate?
> >> I think so, see below.
> >>>> I think not automatically. You would have to mark your synonym as
> >>>> immediate. It can conceivably be useful to define a non-immediate
> >>>> synonym of an immediate word.
> >>> According to the spec it's not portable. In the case of my Forth, the
> >>> word can be marked immediate because the old word's definition is
> >>> copied to newname. I can envisage dictionaries where the
> >>> implementation has names and pointers to header structures; in which
> >>> case, a shared header structure would result in also marking oldname
> >>> as immediate.
> >>> 15.6.2. SYNONYM TOOLS EXT
> >>> ( “<spaces>newname” “<spaces>oldname” -- ) X:synonym
> >>> For both strings skip leading space delimiters. Parse newname and
> >>> oldname delimited by a space. Create a definition for newname with the
> >>> semantics defined below. Newname may be the same as oldname; when
> >>> looking up oldname, newname shall not be found.
> >>> An ambiguous conditions exists if oldname can not be found or
> >>> IMMEDIATE is applied to newname.
> >> <quote>
> >> newname interpretation: ( i*x -- j*x )
> >> Perform the interpretation semantics of oldname.
> >> newname compilation: ( i*x -- j*x )
> >> Perform the compilation semantics of oldname.
> >> </quote>
> >> If oldname is immediate and an implementation doesn't make newname
> >> immediate then their compilation semantics are different which violates
> >> the second statement above.
> >> Therefore ISTM that immediacy must be inherited and the answer to
> >> Bruce's original question is yes.
> >> --
> >> Gerry
> > Elizabeth was suggesting immediacy can be set on newname when oldname
> > is not immediate,
> Not the way I read it, she was referring to an immediate oldname and
> attempting to make newname match it by use of immediate ...
> > which is ambiguous;
> Correct
> > : foo ;
> > synonym bar foo immediate
> > This is ok;
> > : foo ; immediate
> > synonym bar foo
> Yes and bar is automatically immediate (or should be).
On Friday, 10 February 2012 09:32:53 UTC, Gerry wrote:
> You omitted the next bit of the specification that the above refers to > for semantics and which says (from > www.forth200x.org/documents/forth11-1.pdf):
> <quote>
> newname interpretation: ( i*x -- j*x )
> Perform the interpretation semantics of oldname.
> newname compilation: ( i*x -- j*x )
> Perform the compilation semantics of oldname.
> </quote>
> If oldname is immediate and an implementation doesn't make newname > immediate then their compilation semantics are different which violates > the second statement above.
Further, if a system has words with non-default and non-immediate semantics, shouldn't ' newname ( and ['] newname at runtime) return the interpretation semantics of oldname, and POSTPONE newname compile the compilation semantics of oldname, regardless of later STATE?
I'm beginning to see a way to Standardise such words, and still keep an interpreter that uses FIND:
: CLONE ( xt xtc ++ )
CREATE 2, IMMEDIATE DOES> 2@ STATE @ 0= IF DROP THEN EXECUTE ;
CLONE? ( xt -- f ) system dependent. I /think/ you can always non-portably
recognize a DOES> word from its xt
: 'COMP ( ++ xt xtc ) FIND ?DUP 0= IF COUNT TYPE [CHAR] ? EMIT ABORT THEN -1 = IF ['] COMPILE ELSE
DUP CLONE? IF >BODY 2@ ELSE ['] EXECUTE THEN ;
On Feb 10, 4:32 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
wrote:
>>>> Is the SYNONYM of an immediate word defined to be immediate?
> I think so, see below.
...
> You omitted the next bit of the specification that
> the above refers to for semantics and which says
> (fromwww.forth200x.org/documents/forth11-1.pdf): > <quote>
> newname interpretation: ( i*x -- j*x )
> Perform the interpretation semantics of oldname.
> newname compilation: ( i*x -- j*x )
> Perform the compilation semantics of oldname.
> </quote>
OK, thanks.
Then:
CREATE &BUFFER S" SYNONYM" S, 64 CHARS ALLOT
... and something to paste two copies of the "name" into that buffer
just saving the original count and doing a BL> and S> twice would load
up the word, then restore the original count and its ready for the
next use ... would support a "&" that took one copy of the name, and
then evaluate the buffer ... without the complication of handling the
immediacy itself, and also working for words that have more than just
EXECUTE and COMPILE, as compilation semantics.
