RfD: SYNONYM
Stephen Pelc
Synonym.txt
Stephen Pelc, 21 August 2006
20060821 First draft
Rationale
=========
Problem
-------
Various words have been used to gneration a new name for an
existing word. This required when porting code and when
generating application wordlists that contain a reference
to an existing word, e.g. when providing limited access
to Forth system kernel words.
Especially with native code compiling Forth systems, these
words have not provided full access to the required behaviour
which requires carnal knowledge of the underlying system, which
is one reason why SYNONYM should be standardised.
Current practice
----------------
The proposed form SYNONYM has been in use at MPE with cross
compilers and VFX Forth since 1998.
Solution
--------
Although many people have objected to parsing words, parsing
permits the host system the most flexibility in implementation
and is thus the preferred solution.
The syntax is:
SYNONYM <newname> <oldname>
where <newname> will behave identically to <oldname>.
Note that <newname> may be the same as <oldname>.
Proposal
========
10.6.2.xxxx SYNONYM
synonym FACILITY EXT
( "<spaces>newname" "<spaces>oldname" -- )
For both strings kip leading space delimiters. Parse name
delimited by a space. Create a new word newname whose
execution behaviour is identical to that of the existing word
oldname. Newname may be the same as oldname.
Ambiguous conditions:
The word newname is parsed by ' or ['] or POSTPONE.
oldname is not found.
Labelling
=========
TBD
Reference Implementation
========================
The implementation of SYNONYM requires carnal knowledge of the host
implementation, which is one reason why it should be standardised.
The implementation below is imperfect and specific to VFX Forth.
: Synonym \ <"new-name"> <"curdef"> --
\ *G Create a new definition which redirects to an existing one.
create immediate
hide ' , reveal
does>
@ state @ 0= over immediate? or
if execute else compile, then
;
Test Cases
==========
TBD
--
Stephen Pelc, steph...@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
George Hubert
Win32Forth already supports SYNONYM with the same syntax.
George Hubert
Andreas Kochenburger
> SYNONYM <newname> <oldname>
> where <newname> will behave identically to <oldname>.
ALIAS is used for the same purpose
' <oldname> ALIAS NEWNAME
Its syntax is similar to IS.
My personal vote is for ALIAS
J Thomas
Stephen Pelc wrote:
> Especially with native code compiling Forth systems, these
> words have not provided full access to the required behaviour
> which requires carnal knowledge of the underlying system, which
> is one reason why SYNONYM should be standardised.
....
> Ambiguous conditions:
> The word newname is parsed by ' or ['] or POSTPONE.
> oldname is not found.
I see no particular reason not to standardise this just as you say.
It's already reasonably common practice.
As a side issue, what behavior will a portable SYNONYM written in
standard Forth fail at, that doesn't involve ' or ['] or POSTPONE ? I
haven't found anything quickly.
This is as close as I came:
SYNONYM MY-DUP DUP
SYNONYM YOUR-DUP MY-DUP
A portable SYNONYM would probably use ' or ['] or POSTPONE on MY-DUP
here and fit the ambiguous condition, but a primitive SYNONYM wouldn't
have to.
Coos Haak
I've been using this for years. Seems it is older than SYNONYM.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Stephen Pelc
It breaks on some systems (and they exist) that cannot get from
the xt of a word to enough needed information to create the new
word. The point of SYNONYM is that it can be as carnal as necessary.
Stephen
pablo reda
?
I ask from ignorance but I don't think if is necessary,
I have only 1 year of forth programing..and 25 of others..
Ed
"George Hubert" <george...@yahoo.co.uk> wrote in message
news:1156177696.8...@m73g2000cwd.googlegroups.com...
>
> Stephen Pelc wrote:
> > RfD - Synonyms
> > The syntax is:
> > SYNONYM <newname> <oldname>
> > where <newname> will behave identically to <oldname>.
> >
> > Note that <newname> may be the same as <oldname>.
>
> Win32Forth already supports SYNONYM with the same syntax.
Not so fast :)
I wonder how many missed the part in the spec about making
aliases with the same name!
A conforming SYNONYM should be able to handle this:
\ Test SYNONYM ability to make alias with same name
CR
FORTH ALSO DEFINITIONS
: TEST ." hello " ;
VOCABULARY NEWVOC
NEWVOC DEFINITIONS
SYNONYM TEST TEST ( make alias in new vocab )
CR .( now testing alias ) CR
NEWVOC TEST
Alex McDonald
You're right; Win32Forth fails this test due to a timing issue creating
the dictionary entry. At the point where SYNONYM is executed, the ORDER
is
order
Context: NEWVOC FORTH FORTH ROOT
Current: NEWVOC ok
TEST is being defined, then searched for, rather than searched for then
defined; so it finds itself rather than the TEST in the FORTH
vocabulary. WIll be corrected.
--
Regards
Alex McDonald
George Hubert
Ed wrote:
> "George Hubert" <george...@yahoo.co.uk> wrote in message
> news:1156177696.8...@m73g2000cwd.googlegroups.com...
> >
> > Stephen Pelc wrote:
> > > RfD - Synonyms
> > > ...
> > > The syntax is:
> > > SYNONYM <newname> <oldname>
> > > where <newname> will behave identically to <oldname>.
> > >
> > > Note that <newname> may be the same as <oldname>.
> >
> > ...
> > Win32Forth already supports SYNONYM with the same syntax.
>
> Not so fast :)
>
How slow do you want it. -;)
> I wonder how many missed the part in the spec about making
> aliases with the same name!
>
Not me I saw it.
> A conforming SYNONYM should be able to handle this:
>
> \ Test SYNONYM ability to make alias with same name
> CR
> FORTH ALSO DEFINITIONS
> : TEST ." hello " ;
> VOCABULARY NEWVOC
> NEWVOC DEFINITIONS
> SYNONYM TEST TEST ( make alias in new vocab )
> CR .( now testing alias ) CR
> NEWVOC TEST
Win32Forth supports that. I've used both SYNONYM and ALIAS (which
always makes the new word non-immediate irrespective of the immediacy
of the original) to have the same word in diffrent vocabularies many a
time. It's even used in the system for putting FORTH FORTH-WORDLIST and
SET-ORDER in the ROOT vocabulary (the one that's always available after
ONLY) as well as the FORTH vocabulary, so I know it works.
George Hubert
Alex McDonald
Are you sure? I've just run it under 6.11.07 and it fails.
--
Regards
Alex McDonald
George Hubert
All it needs is to hide the new word until after the second word is
looked up, which has the added advantage that if old-word isn't found
then new-word is hidden (similar to an incomplete : definition).
George Hubert
George Hubert
You're right (although the latest V6.11.09 from the cvs now works
correctly). It's ALIAS (where the xt is passed in) that worked whatever
the search order; SYNONYM requires the voc of old word to be earlier in
the search-order than the current voc. I couldn't run Ed's test for the
original post (or any other) since it hadn't been posted at the time.
V6.10 will also be modified to match; it just requires HIDE and REVEAL.
>
> --
> Regards
> Alex McDonald
George Hubert
J Thomas
For a word "with default compilation behavior" it's easy.
: SYNONYM
:
BL WORD FIND DROP COMPILE,
POSTPONE ; ;
You wind up with a new word that calls the old word. Standard programs
won't do R> DROP etc so they can't tell the difference between doing
one call and one return versus two calls and two returns. It ought to
just work.
But when you try to get synonyms for words that are active at compile
time then you run into all the problems Anton Ertl pointed out for
state-smartness etc. You need two behaviors that will each happen at
precisely the right times and not at the wrong times, and there's no
way to be sure to get those behaviors with all combinations of
compilation, execution, POSTPONE, EXECUTE, and EVALUATE .
But Anton published a portable solution to that problem, where each
word gets two execution tokens and the system is instructed (in a
portable way) which of them to use. And it seems to me that if you use
Anton's system, you should be able to extend it simply for synonyms.
You can easily get the two xt's for the old word, and you can construct
the new word with them. So SYNONYM should be as portable as Anton's
method, for that particular set of problems.
What other portability problems are there?
George Hubert
J Thomas wrote:
> How would you attempt to write a portable definition for SYNONYM?
>
> For a word "with default compilation behavior" it's easy.
>
> : SYNONYM
> :
> BL WORD FIND DROP COMPILE,
> POSTPONE ; ;
Why not;
: SYNONYM
:
BL WORD FIND 1 = IF IMMEDIATE THEN COMPILE,
POSTPONE ; ;
which takes care of whether the word is IMMEDIATE as well, although
neither version deals with the case of oldword not being found. It
wouldn't work correctly with separate intepret and compile xts though.
> You wind up with a new word that calls the old word. Standard programs
> won't do R> DROP etc so they can't tell the difference between doing
> one call and one return versus two calls and two returns. It ought to
> just work.
>
Somebody will want a synonym for R> >R for some obscure reason -;)
> But when you try to get synonyms for words that are active at compile
> time then you run into all the problems Anton Ertl pointed out for
> state-smartness etc. You need two behaviors that will each happen at
> precisely the right times and not at the wrong times, and there's no
> way to be sure to get those behaviors with all combinations of
> compilation, execution, POSTPONE, EXECUTE, and EVALUATE .
>
> But Anton published a portable solution to that problem, where each
> word gets two execution tokens and the system is instructed (in a
> portable way) which of them to use. And it seems to me that if you use
> Anton's system, you should be able to extend it simply for synonyms.
> You can easily get the two xt's for the old word, and you can construct
> the new word with them. So SYNONYM should be as portable as Anton's
> method, for that particular set of problems.
>
Depending on how dual xts are implemented it's possible to make SYNONYM
just point the name of to the same address as oldword points to, though
this means the 2 words behave exactly the same forevermore (i.e. if you
supply an optimised compile to newword then compiling oldword does the
same optimising from then on as well).
> What other portability problems are there?
Probably many. Separate wordlists for compilation words springs to
mind. I don't think a portable version for all systems is possible
though ones can be written for common implementation strategies; IMO
that's probably why it needs standardising.
George Hubert
GerryJ
> Proposal
> ========
> 10.6.2.xxxx SYNONYM
> synonym FACILITY EXT
>
> ( "<spaces>newname" "<spaces>oldname" -- )
> For both strings kip leading space delimiters. Parse name
> delimited by a space. Create a new word newname whose
> execution behaviour is identical to that of the existing word
> oldname. Newname may be the same as oldname.
>
> Ambiguous conditions:
> The word newname is parsed by ' or ['] or POSTPONE.
> oldname is not found.
>
> ========================
> The implementation of SYNONYM requires carnal knowledge of the host
> implementation, which is one reason why it should be standardised.
> The implementation below is imperfect and specific to VFX Forth.
>
> : Synonym \ <"new-name"> <"curdef"> --
> \ *G Create a new definition which redirects to an existing one.
> create immediate
> hide ' , reveal
> does>
> @ state @ 0= over immediate? or
> if execute else compile, then
> ;
>
I've just implemented this as it seems a useful addition, although I
would have preferred SYNONYM <oldname> <newname> as it seems more
natural to find the old one before creating the new name but no matter.
I have the following questions, (nit picking I know but it is for a
standard):
1. Your reference implementation creates a new immediate word.
Therefore FIND <newname> will return a different result to FIND
<oldname> both due to a different xt (probably) and because <oldname>
may not be immediate. Does this matter?
2. If an implementation is an exact synonym i.e. FIND returns the same
xt and <newname> follows <oldname> immediacy as well as behaving
exactly the same, does SYNONYM count as a defining word in the terms of
the ANS standard e.g. if the old word abc is not immediate will
SYNONYM xyz abc IMMEDIATE
make xyz or the previous definition immediate, or should it make both
xyz and abc immediate or is it an ambiguous condition. I think making
only xyz immediate is the best.
3. Just thought of this as I was about to post this message. With your
implementation would the following work?
SYNONYM ENDIF THEN
For the record my implementation creates an exact synonym so ' ['] and
POSTPONE will all work with <newname> which I think is better than
making that an ambiguous condition.
Gerry
J Thomas
George Hubert wrote:
> J Thomas wrote:
> > How would you attempt to write a portable definition for SYNONYM?
> > For a word "with default compilation behavior" it's easy.
> > : SYNONYM
> > :
> > BL WORD FIND DROP COMPILE,
> > POSTPONE ; ;
> Why not;
> : SYNONYM
> :
> BL WORD FIND 1 = IF IMMEDIATE THEN COMPILE,
> POSTPONE ; ;
I dunno. That might work. There were a lot of traps and I haven't
thought about it for awhile, maybe some of them would bite you on this.
To be on the safe side it might make sense to make it immediate after
you've postponed ; but I've never noticed an implementation that won't
make an incomplete definition immediate.
> which takes care of whether the word is IMMEDIATE as well, although
> neither version deals with the case of oldword not being found. It
> wouldn't work correctly with separate intepret and compile xts though.
Yes. Two incompatible systems. One has tradition and the other works
better.
> Somebody will want a synonym for R> >R for some obscure reason -;)
Oops! You got me there. So the simple implementation fails even when R>
>R have no special compilation behavior. So it fails.
> Depending on how dual xts are implemented it's possible to make SYNONYM
> just point the name of to the same address as oldword points to, though
> this means the 2 words behave exactly the same forevermore (i.e. if you
> supply an optimised compile to newword then compiling oldword does the
> same optimising from then on as well).
Yes.
> > What other portability problems are there?
> Probably many. Separate wordlists for compilation words springs to
> mind. I don't think a portable version for all systems is possible
> though ones can be written for common implementation strategies; IMO
> that's probably why it needs standardising.
Have you figured out how to do separate wordlists for compilation words
in a standard system? When I tried that it turned into a briar patch.
Define a new word with the old name that isn't immediate, and watch the
old version get found during compilation. Etc. Getting the standard
behaviors seemed to beg for a synonym in whichever wordset you aren't
defining in at the moment. Those systems are designed to work different
from standard, and it wrenches their soul to try to make them conform.
Anyway, if Anton's dual-wordlist approach can be implemented on any
standard system using only standard words, then it looks to me like
adding SYNONYM to it ought to be trivial. So SYNONYM should be very
widely portable.
Albert van der Horst
J Thomas <jeth...@gmail.com> wrote:
>How would you attempt to write a portable definition for SYNONYM?
>
>
>What other portability problems are there?
>
I want to remark that it is important to standardize words
that *cannot* be portably implemented, or not efficiently.
It is much less important to standardize words that can
be portably implemented, as they can always be made
part of the application.
--
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Alex McDonald
Well, for the case of SYNONYM in the latest dual-xt version of W32F
based on Anton's suggestions (see here
http://www.complang.tuwien.ac.at/forth/header-ideas.html), it will be
important. To ensure the right behaviour with dual xts for words that
have non-standard compilation semantics, the synonym must either be an
immediate word that always executes the compile token of the underlying
word, or a complete copy of the dictionary entry. I can't think of a
portable ANS way to implement SYNONYM that would support such systems.
As an aside, this version of W32F passes the postpone test
(http://www.complang.tuwien.ac.at/forth/postponetest.fs).
--
Regards
Alex McDonald
Stephen Pelc
<ge...@jackson9000.fsnet.co.uk> wrote:
>1. Your reference implementation creates a new immediate word.
>Therefore FIND <newname> will return a different result to FIND
><oldname> both due to a different xt (probably) and because <oldname>
>may not be immediate. Does this matter?
No.
>2. If an implementation is an exact synonym i.e. FIND returns the same
>xt and <newname> follows <oldname> immediacy as well as behaving
>exactly the same, does SYNONYM count as a defining word in the terms of
>the ANS standard e.g. if the old word abc is not immediate will
>
> SYNONYM xyz abc IMMEDIATE
>
>make xyz or the previous definition immediate, or should it make both
>xyz and abc immediate or is it an ambiguous condition. I think making
>only xyz immediate is the best.
IMMEDIATE affects the last dictionary entry which is XYZ.
I have already made this an ambiguous condition.
>3. Just thought of this as I was about to post this message. With your
>implementation would the following work?
> SYNONYM ENDIF THEN
Yes.
Stephen
Anton Ertl
>Proposal
>========
>10.6.2.xxxx SYNONYM
>synonym FACILITY EXT
>
>( "<spaces>newname" "<spaces>oldname" -- )
>For both strings kip leading space delimiters. Parse name
> delimited by a space. Create a new word newname whose
>execution behaviour is identical to that of the existing word
>oldname.
"execution behaviour" is not a standard term. If you mean "execution
semantics", then SYNONYM is no more powerful than ALIAS. If you want
to make SYNONYM more powerful than ALIAS, how about the following
specification:
... Create a definition for newname with the semantics defined below:
newname interpretation: ( i*x -- j*x )
Perform the interpretation semantics of oldname
newname compilation: ( i*x -- j*x )
Perform the compilation semantics of oldname
> Newname may be the same as oldname.
That's true by default, so leave it away here; you may want to point
it out in an informal part.
>Ambiguous conditions:
> The word newname is parsed by ' or ['] or POSTPONE.
No! If you can tick or POSTONE oldname, you should also be able to do
this to newname, or it won't be a synonym. Moreover, having words
that cannot be ticked or postponed in the standard is bad enough, we
don't need to add defining words for such monstrosities; I would
consider a language that had such defining words to be not Forth.
Also, I don't see a technical reason for such a restriction
(especially if you don't make [COMPILE] newword ambiguous).
- 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 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
Anton Ertl
>But Anton published a portable solution to that problem, where each
>word gets two execution tokens and the system is instructed (in a
>portable way) which of them to use.
Actually my implementation has bugs, but since nobody seemed
interested, fixing them never got to the top of my agenda.
> And it seems to me that if you use
>Anton's system, you should be able to extend it simply for synonyms.
>
>You can easily get the two xt's for the old word,
Does not seems so easy to me.
Hmm, the xt for the compilation semantics could be constructed like
this:
:noname POSTPONE oldname ;
The interpretation semantics might be gotten by just ticking the word
(and maybe CATCHING any errors). But for words with undefined
interpretation semantics, one might not get what one wants.
Still, it looks like it is possible to do it (apart from the return
stack words, as someone else mentioned).
Anton Ertl
>Why not;
>
>: SYNONYM
> :
> BL WORD FIND 1 = IF IMMEDIATE THEN COMPILE,
> POSTPONE ; ;
|6.1.1550 ... For a given string, the values returned by FIND while
|compiling may differ from those returned while not compiling.
In any case, this version of SYNONYM would not work as it should when
defining a synonym for S" on Gforth.
>It
>wouldn't work correctly with separate intepret and compile xts though.
Yes, that's it.
Anton Ertl
>Have you figured out how to do separate wordlists for compilation words
>in a standard system? When I tried that it turned into a briar patch.
>Define a new word with the old name that isn't immediate, and watch the
>old version get found during compilation.
I think the right approach is to have a wordlist for the
interpretation/execution semantics of standard words, a wordlist for
the compilation semantics of standard words, and a wordlist for
user-defined words. In interpretation state, you search user, then
interpretation; in compilation state, you search user, then
compilation, then interpretation.
Of course, this scheme becomes complicated once you want to implement
the search-order wordset, so complicated that it isn't worth doing.
Mark W. Humphries
Anton Ertl wrote:
> I think the right approach is to have a wordlist for the
> interpretation/execution semantics of standard words, a wordlist for
> the compilation semantics of standard words, and a wordlist for
> user-defined words. In interpretation state, you search user, then
> interpretation; in compilation state, you search user, then
> compilation, then interpretation.
I find it simpler to reserve 2 extra bits in each header, an
interpretation bit, a compilation bit, in addition to the traditional
precedence (i.e. immediate) bit.
A normal word has interpretation=1 compilation=1 precedence=0
A normal immediate word has i=1 c=1 p=0
A compile-only non-immediate word has i=0 c=1 p=0
A directive (i.e. compile-only immediate) word has i=0 c=1 p=1
An interpret-only word has i=1 c=0 p=0
Cheers,
Mark W. Humphries
Manila, Philippines
Mark W. Humphries
> A normal immediate word has i=1 c=1 p=0
J Thomas
> "J Thomas" <jeth...@gmail.com> writes:
> >But Anton published a portable solution to that problem, where each
> >word gets two execution tokens and the system is instructed (in a
> >portable way) which of them to use.
> >Anton's system, you should be able to extend it simply for synonyms.
> >You can easily get the two xt's for the old word,
> Does not seems so easy to me.
I may have misunderstood, or I may be asking too much. I thought, you
came up with an approach that stored two xt's for each word, and an
interpreter/compiler that used those appropriately, and the code which
does that *could* be done correctly and portably. Once a system has
that code ported to it, SYNONYM could use the internals of your code to
copy the two xts to the new word. Your interpreter/compiler would then
treat both words identically.
> Hmm, the xt for the compilation semantics could be constructed like
> this:
> :noname POSTPONE oldname ;
> The interpretation semantics might be gotten by just ticking the word
> (and maybe CATCHING any errors). But for words with undefined
> interpretation semantics, one might not get what one wants.
Yes. But interpreting those words is ambiguous anyway.
> Still, it looks like it is possible to do it (apart from the return
> stack words, as someone else mentioned).
If return stack words are immediate then it's no problem. The copy is
immediate, at compile time it calls the old word which performs its
compile magic and the runtime result is the same. If return stack words
are not immediate then it's no problem. The compiler gets the xt of the
old word and compiles it.
Without the special compiler we're left with a state-smart word, that
in some cases is supposed to give the same result as a non-state-smart
word.
So the only way left I can see is to make the compiler/interpreter do
the work. If every word has two xt's and the compiler chooses which to
use, you can give the same xt's to the synonym that the old word has.
It will behave exactly like the old word.
It isn't easy to do it with wordlists. Say we have 3 wordlists, COMPILE
INTERPRET and FORTH . First we search FORTH . Then we search COMPILE or
INTERPRET and swap the order of those two if we're compiling instead of
interpreting. We avoid the state-smart traps by compiling synonyms into
COMPILE and INTERPRET .
: FOO dosomething ;
SYNONYM FOO BAR
We'll always find the old FOO instead of the new foo. So that doesn't
work.
Say we have only two wordlists, COMPILE and INTERPRET .
: FOO dosomething ; immediate
: FOO somethingelse ;
Now we'll get the old FOO when we compile unless we make two
definitions for each word. That's wasteful but it can be done, the
compiler must automatically define
: FOO [ ' FOO ] LITERAL COMPILE, ;
every time you make a word with standard compile behavior.
If you want multiple wordlists you'll need two real wordlists for each
official wordlist, you'll have an interpret version and a compile
version. And then I think SYNONYM works for nonimmediate >R .
SYNONYM PUSH >R
The compile version will go
: PUSH [ ' >R ] literal compile, ;
so it will do exactly the same thing as >R at compile time.
I rejected this approach the last time I thought about it because I was
using a Forth that fit into 8K and it seemed like unacceptable bloat to
double the number of words. But it might work. Of course if you try to
implement it portably, it will only work on Forths that allow multiple
wordlists, and Forths that allow only 8 wordlists will only have 4
wordlists available to users.
And you'll need a top-level definition something like:
: COLD
BEGIN ['] my-interpreter CATCH handle-exceptions AGAIN ;
And any throw it can't handle itself will dump you back to the original
system.
I think the central problem here comes because the original Forth
interpreter was too simple. One state. You execute or
compile-or-execute, then you check if it's a number. Everything else
could be done by the words themselves. And we wound up with endless
complication in the words themselves. As I understand it, with
ColorForth Chuck has moved on to having 8 or so special tokens that
affect state, and everything else just does one thing. No immediate
words except those tokens, the token says whether to execute or
compile. That's [ ] and you don't compile those into other words. A
token to say it's a number. A token to say it's a character, like CHAR
and [CHAR] . A token to say it's an execution token like ' and ['] .
Chuck doesn't need words that second-guess him about how to handle
source code, he knows what he wants to happen and he can just tell it
to happen.
I think code written that way could be translated into standard Forth
fairly easily. The translator could look at each word, note its default
standard behavior, and see what it had to do to provide it. [ ] CHAR
LITERAL etc. So if you choose to write that way, your code should be
quite portable. And you won't have to worry about how to extend the
standard to allow many forths to all do something complicated and make
it work.
It occurs to me that given a good editor, one possible way to implement
SYNONYM would be to have it do a global search and replace. But only
forward. It doesn't quite work.
Another approach that almost works is
: SYNONYM
:
POSTPONE S"
POSTPONE EVALUATE
POSTPONE ;
IMMEDIATE ;
But that fails for parsing words. There's always something. Traditional
Forth is a brittle about this stuff, too coadapted, too many
interdependencies making it hard to change one thing without breaking
something else.
Stephen Pelc
(Anton Ertl) wrote:
> how about the following specification:
>
>... Create a definition for newname with the semantics defined below:
>
> newname interpretation: ( i*x -- j*x )
> Perform the interpretation semantics of oldname
>
> newname compilation: ( i*x -- j*x )
> Perform the compilation semantics of oldname
Accepted. In the current draft.
>> Newname may be the same as oldname.
>
>That's true by default, so leave it away here; you may want to point
>it out in an informal part.
The statement helps to reduce the number of incorrect implementations!
>>Ambiguous conditions:
>> The word newname is parsed by ' or ['] or POSTPONE.
>
>No! If you can tick or POSTONE oldname, you should also be able to do
>this to newname, or it won't be a synonym. Moreover, having words
>that cannot be ticked or postponed in the standard is bad enough,
{snipped]
The more I explore the implications, the more I gree with you.
But (and it's a big but), there are a huge number of systems out
there that do not comply, and fail under pathological conditions
that "normal" users do not encounter. This includes some MPE
systems.
I would much prefer to mark bad behaviour in this area as being
subject to restriction in the next round. The reason is to
encourage rapid uptake of Forth200x.
Anton Ertl
>On Fri, 25 Aug 2006 20:25:55 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>>> Newname may be the same as oldname.
>>
>>That's true by default, so leave it away here; you may want to point
>>it out in an informal part.
>
>The statement helps to reduce the number of incorrect implementations!
It should also do that if it is in an informal part. In particular,
if you make a test case for this.
>>>Ambiguous conditions:
>>> The word newname is parsed by ' or ['] or POSTPONE.
>>
>>No! If you can tick or POSTONE oldname, you should also be able to do
>>this to newname, or it won't be a synonym. Moreover, having words
>>that cannot be ticked or postponed in the standard is bad enough,
>{snipped]
>
>The more I explore the implications, the more I gree with you.
>But (and it's a big but), there are a huge number of systems out
>there that do not comply, and fail under pathological conditions
>that "normal" users do not encounter. This includes some MPE
>systems.
Can you give an example of such pathological conditions?
>I would much prefer to mark bad behaviour in this area as being
>subject to restriction in the next round.
This will never happen. If a system implementor does not go for
implementing SYNONYM properly the first time, they will resist such a
change later. At that time, any change in implementation has the risk
of breaking existing programs.
>The reason is to
>encourage rapid uptake of Forth200x.
Since SYNONYM is an optional part, they can take up the rest of
Forth200x without implementing SYNONYM. So I don't see that
specifying a proper SYNONYM would slow down the uptake of Forth200x,
or that specifying a broken SYNONYM would speed up the uptake of
Forth200x.
J Thomas
Stephen Pelc wrote:
> >> Newname may be the same as oldname.
> >That's true by default, so leave it away here; you may want to point
> >it out in an informal part.
> The statement helps to reduce the number of incorrect implementations!
Good point!
> >>Ambiguous conditions:
> >> The word newname is parsed by ' or ['] or POSTPONE.
> >No!
> The more I explore the implications, the more I gree with you.
> But (and it's a big but), there are a huge number of systems out
> there that do not comply, and fail under pathological conditions
> that "normal" users do not encounter. This includes some MPE
> systems.
It would be possible to go ahead and declare a correct standard, and
let the noncomplying systems document their small degree of
noncompliance.
A minor problem in the Facilities Extension wordset shouldn't be too
much of a problem for implementors who want to call their systems
standard. And if they don't care about fixing SYNONYM now, why would
they care more later?
Albert van der Horst
J Thomas <jeth...@gmail.com> wrote:
>Anton Ertl wrote:
>> "J Thomas" <jeth...@gmail.com> writes:
>> >But Anton published a portable solution to that problem, where each
>> >word gets two execution tokens and the system is instructed (in a
>> >portable way) which of them to use.
>> > And it seems to me that if you use
>> >Anton's system, you should be able to extend it simply for synonyms.
>
>> >You can easily get the two xt's for the old word,
>
>> Does not seems so easy to me.
>
>
>But that fails for parsing words. There's always something. Traditional
>Forth is a brittle about this stuff, too coadapted, too many
>interdependencies making it hard to change one thing without breaking
>something else.
>
Instead of concentrating on how to implement SYNONYM
I would like to see a careful unambiguous statement about
how it supposed to work.
By the way I hate this word. This would be the first definition
in the standard where parsing is done beyond the next word.
Groetjes Albert
--
Ed
Consider what would happen if the arguments were reversed.
I'll call it SYNONYM2 -
SYNONYM2 <oldname> <newname>
With this syntax, there's no temporal issue and hiding/revealing
is not necessary. If <oldname> isn't found then nothing is
created in the dictionary.
SYNONYM takes more effort to implement on systems where
xt must be known at head creation. In contrast, SYNONYM2
has all the information available at create time.
IMO, for alias creation the syntax <oldname> <newname>
is technically superior.
I also have concerns with the name. Given its frequency
SYNONYM is far too long to type (and a horror to spell :)
Can we do better?
-------------
"Common practice" is not necessarily "best practice".
Neal Bridges
news:44f12...@news.chariot.net.au...
[snip]
> > > > > > The syntax is:
> > > > > > SYNONYM <newname> <oldname>
> IMO, for alias creation the syntax <oldname> <newname>
> is technically superior.
>
> I also have concerns with the name. Given its frequency
> SYNONYM is far too long to type (and a horror to spell :)
> Can we do better?
As I recall it from the beginning of this thread, the argument against
ALIAS
' oldname ALIAS newname
was that some systems find it hard to support finding the oldname word
header from the xt, and so wouldn't be able to find all the details it might
need to properly alias it. Is that reason enough to introduce this
double-forward-parsing SYNONYM monstrostity that *still* can't guarantee
that newname will share all the characteristics of oldname?
ALIAS is already demonstrably common-usage, and ideally will create an exact
duplicate of oldname, flags and semantics and all. If a given Forth can't
do that, so be it. If so few Forths can do that that it doesn't warrant
being discussed as a new standard, so be it. Let's not add a new word that
is simultaneously ugly, short on functionality, and riddled with ambiguous
conditions.
--
Neal Bridges
http://quartus.net Home of Quartus Forth for the Palm OS!
mli...@gmail.com
Albert van der Horst wrote:
> Instead of concentrating on how to implement SYNONYM
> I would like to see a careful unambiguous statement about
> how it supposed to work.
What it's supposed to do, is let you add a second name whose behavior
is exactly like an existing definition. Or close enough that the
differences don't cause trouble.
This aids code portability. It doesn't so much help port standard code
among standard systems. It's potentially a big help for porting
standard code to nonstandard systems, or nonstandard code to standard
systems.
Say you want to port a big body of code to a new system, and it turns
out that one of them uses THEN and the other uses ENDIF . One solution
is to take a text editor and do a global replace on every file you want
to port. That might be the best way, although you may get a few
comments like "First we do x, and ENDIF we do y".
Another method is to use whatever programming tools are available from
the Forth you're porting to, and find the definition of ENDIF , and
make THEN with exactly the same definition. That's an inconvenience but
not so very hard. But SYNONYM lets you do it without knowing anything
about how the old word works.
It looks to me like the main value for SYNONYM is that it lets you make
things just work. You can write code that you can hope will port
effortlessly to many systems. If there's a Forth expert for each system
who can spare the time to track down all the problems, then SYNONYM
isn't that valuable. All SYNONYM gives you is the chance to make things
work without having to know all the details.
If you can define it portably, there isn't nearly as much need to
standardise it. You can put it into a library and anybody who wants to
use it can just compile the reference version. Or if they want to
improve performance they can come up with a version that's better for
their system, and if it passes the test suite it's probably OK.
You might argue that there's no need for SYNONYM . But all the people
who discuss the details of how to write the standards document for it,
think it's worth doing. If you think it isn't worth doing then make the
argument.
> By the way I hate this word. This would be the first definition
> in the standard where parsing is done beyond the next word.
\ parses to the end of the line. (( parses until it reaches a )) or end
of file, although (( isn't defined in the standard, it's just written
using standard code. There are probably others.
It needn't be such a big deal about the order of the words. Do
>IN @ BL WORD >IN @ BL WORD
and you can back up to either word and parse it whenever you want.It's
just a little extra stack juggling. I prefer the old name first and
then the new name, but there's historical pecedent the other way. And
it doens't look like a lot of difficulty to me, now.
Marcel Hendrix
[..]
> I also have concerns with the name. Given its frequency
> SYNONYM is far too long to type (and a horror to spell :)
> Can we do better?
"Given its frequency?" I have counted occurrences of ALIAS, AKA and
SYNONYM in all the files (over 7,000 in total) I have for SwiftForth
(80), VFX (5), Win32Forth (47), gForth (13) and iForth (0). (There
are more references, but that's in documentation and defining the
words themselves.)
In many cases I saw, it seems that doing : bar ... ; : foo bar ;
would be perfectly adequate as bar has no special characteristics
and foo is not time-critical.
I'm not against standardizing this word; it is obviously in use
by many Forths with conflicting names. But I am curious what's so
fascinating about this word?
I will always need to look up the documentation for SYNONYM, is
it <oldword> <newword> or the reverse?
Clearer would be :SYNONYM <newname> <oldname> SYNONYM; or
:SYNONYM <newname> <oldname> ;
-marcel
Marcel Hendrix
> Say you want to port a big body of code to a new system, and it turns
> out that one of them uses THEN and the other uses ENDIF . One solution
> is to take a text editor and do a global replace on every file you want
> to port. That might be the best way, although you may get a few
> comments like "First we do x, and ENDIF we do y".
Unless that code does : BAR S" ENDIF" EVALUATE ; IMMEDIATE
or ...
If I use SEE on a word using a SYNONYM, which name is shown?
-marcel
Anton Ertl
>ALIAS is already demonstrably common-usage, and ideally will create an exact
>duplicate of oldname, flags and semantics and all.
Such an ALIAS has a conflict with Gforth's ALIAS, which just produces
a word that has the execution/interpretation semantics specified by
the xt, but default compilation semantics. In particular, it is not
immediate, whether the ticked word is immediate or not.
So a least common denominator would make the compilation semantics of
an ALIAS undefined, unless the original had default cmpilation
semantics (then it has default compilation semantics), or unless
IMMEDIATE is applied (then it is immediate).
With such an ALIAS, we cannot do as easily what SYNONYM can do, but we
can combine it with other techniques to achieve the same
functionality:
For a word with default compilation semantics, use
' R@ alias my-r@
For an immediate word, use
' ( alias my-* immediate
For a word with non-default compilation semantics und undefined
interpretation semantics, use:
: endif POSTPONE then ; immediate
For a word with defined interpretation semantics and non-default,
non-immediate compilation semantics, you could define it in a
STATE-smart way (and it will fail when the original will also fail on
some system), or you could use the refined technique discussed in
http://www.complang.tuwien.ac.at/forth/dpans-html/comment-semantics.html;
for simplicity, here's the state-smart variant:
: my-s"
state @ if
postpone S"
else
['] S" execute
then ; immediate
So what SYNONYM offers above ALIAS is the convenience of not having to
make this case analysis.
Anton Ertl
>"Ed" <nos...@invalid.com> writes Re: RfD: SYNONYM
>[..]
>> I also have concerns with the name. Given its frequency
>> SYNONYM is far too long to type (and a horror to spell :)
>> Can we do better?
>
>"Given its frequency?" I have counted occurrences of ALIAS, AKA and
>SYNONYM in all the files (over 7,000 in total) I have for SwiftForth
>(80), VFX (5), Win32Forth (47), gForth (13) and iForth (0). (There
>are more references, but that's in documentation and defining the
>words themselves.)
Hmm:
[~/gforth:52244] find . -name \*.fs| xargs grep -i alias|wc -l
218
Some of these are in comments, but most are actual uses.
>I will always need to look up the documentation for SYNONYM, is
>it <oldword> <newword> or the reverse?
I also see this problem.
>Clearer would be :SYNONYM <newname> <oldname> SYNONYM; or
>:SYNONYM <newname> <oldname> ;
Yes; or a self-documenting name that contains NEW and OLD in the order
needed by the syntax. E.g., in the simplest case:
NEW-OLD newname oldname
David N. Williams
> m...@iae.nl (Marcel Hendrix) writes:
. [...]
>> I will always need to look up the documentation for SYNONYM, is
>> it <oldword> <newword> or the reverse?
>
> I also see this problem.
>
>> Clearer would be :SYNONYM <newname> <oldname> SYNONYM; or
>> :SYNONYM <newname> <oldname> ;
>
> Yes; or a self-documenting name that contains NEW and OLD in the order
> needed by the syntax. E.g., in the simplest case:
>
> NEW-OLD newname oldname
What about NEW-NAME for the version of ALIAS with the function
of SYNONYM?
' oldname NEW-NAME newname
-- David
Anton Ertl
>What about NEW-NAME for the version of ALIAS with the function
>of SYNONYM?
>
> ' oldname NEW-NAME newname
An xt does not contain enough information for performing the function
of SYNONYM.
Conversely, you can do things with ALIAS that you cannot do with
SYNONYM: give a name to an anonymous word:
:noname ... ; alias foo
Or if you have access to the xt, but not easily to the name. E.g.:
' deferred-word defer@ alias bar
If we wanted to have a word with the functionality of SYNONYM where we
pass the oldname on the stack, the best approach would be to introduce
a name token (implemented as NFA on most systems), and pass that.
E.g., something like:
s" oldname" FIND-NAME ( nt ) NEW-NAME newname
But I guess that this proposal would then have to wait until we had
one for name tokens and their related words.
David N. Williams
> "David N. Williams" <will...@umich.edu> writes:
>> What about NEW-NAME for the version of ALIAS with the function
>> of SYNONYM?
>>
>> ' oldname NEW-NAME newname
>
> An xt does not contain enough information for performing the function
> of SYNONYM.
I thought you might say that! :-)
-- David
Anton Ertl
>Anton Ertl wrote:
>> "J Thomas" <jeth...@gmail.com> writes:
>> >You can easily get the two xt's for the old word,
>
>> Does not seems so easy to me.
>
>I may have misunderstood, or I may be asking too much. I thought, you
>came up with an approach that stored two xt's for each word, and an
>interpreter/compiler that used those appropriately, and the code which
>does that *could* be done correctly and portably.
Yes.
> Once a system has
>that code ported to it, SYNONYM could use the internals of your code to
>copy the two xts to the new word.
Yes, but then SYNONYM would work only for oldwords defined in that
way. But for, e.g., the words originally in the system, getting the
necessary xts could be a problem.
>> The interpretation semantics might be gotten by just ticking the word
>> (and maybe CATCHING any errors). But for words with undefined
>> interpretation semantics, one might not get what one wants.
>
>Yes. But interpreting those words is ambiguous anyway.
Yes, so as long as you don't want to copy the system-defined
interpretation semantics, you should be all right.
>If return stack words
>are not immediate then it's no problem. The compiler gets the xt of the
>old word and compiles it.
Sorry, you lost me here.
>So the only way left I can see is to make the compiler/interpreter do
>the work. If every word has two xt's and the compiler chooses which to
>use, you can give the same xt's to the synonym that the old word has.
>It will behave exactly like the old word.
Yes, but the original words in the system don't have two xts. And my
program uses the definition only for words that are likely to be
implemented in a STATE-smart way in the system.
>It isn't easy to do it with wordlists.
No, the wordlists approach is no good for letting users define
combined words and similar things. Actually, the fact that no
standard systems have appeared that use it indicates that there are
better ways for implementing standard systems.
>It occurs to me that given a good editor, one possible way to implement
>SYNONYM would be to have it do a global search and replace. But only
>forward. It doesn't quite work.
One significant use of SYNONYM/ALIAS is to put the same name in
several wordlists.
Alex McDonald
> If we wanted to have a word with the functionality of SYNONYM where we
> pass the oldname on the stack, the best approach would be to introduce
> a name token (implemented as NFA on most systems), and pass that.
> E.g., something like:
>
> s" oldname" FIND-NAME ( nt ) NEW-NAME newname
>
> But I guess that this proposal would then have to wait until we had
> one for name tokens and their related words.
Which would appear to be more important than something that is
implementable with
vocabulary vnew
also vnew definitions
: newname oldname ;
previous definitions
in any ANS system; unless there's something about SYNONYM that I'm
missing that makes it only implementable with carnal knowledge..
--
Regards
Alex McDonald
J Thomas
Marcel Hendrix wrote:
> If I use SEE on a word using a SYNONYM, which name is shown?
I don't care.
Peter Fälth
Yes on my system it needs to do an exact duplicate of the oldword.
The only difference is the name. The new name points to the same
executable code.
It is mainly used in the metacompiler on words with special compilation
actions.
My system has 2 xts for every word
With a set of words to access the header information it is easy to
define
: synonym ( -- ) \ use as synonym new old makes a twin of old and
names it new
header \ create
new header
parse-word findheader found? \ find old header
reveal
\ make new header
findable
dup >xtr @ last-head @ >xtr ! \ copy the
execution addr
dup ht>len w@ last-head @ ht>len w! \ copy len of execution
code
dup ht>lenc c@ last-head @ ht>lenc c! \ copy len of compilation
code
dup ht>flag c@ last-head @ ht>flag c! \ copy flags
>xtc @ set-xtc ; \ copy the
compilation addr
regards
peter
>
> --
> Regards
> Alex McDonald
J Thomas
> > Once a system has
> >that code ported to it, SYNONYM could use the internals of your code to
> >copy the two xts to the new word.
> Yes, but then SYNONYM would work only for oldwords defined in that
> way. But for, e.g., the words originally in the system, getting the
> necessary xts could be a problem.
It should be possible to redefine every oldword (or maybe just all the
standard words your code will use), using the methods you described
above. For compile-only words you might not get the interpret behavior
you want (if you get an error you can give them an xt that will
announce an error and throw). You *might* get great interpret behavior
you don't expect. interpreted DO loops etc, that are not standard
partly because we can't expect legacy systems to implement them.
You don't know what you'd get, but you don't know what you'll get if
you try to intepret those oldwords either so it's only reasonable the
newwords would be the same way.
> >If return stack words
> >are not immediate then it's no problem. The compiler gets the xt of the
> >old word and compiles it.
> Sorry, you lost me here.
>R etc can be implemented as compiler words that do something special at compile time. Or they can be simply nonimmediate words that violate the standard return stack conventions in a system-dependent way to get their result. They're listed as compiler-only words because their behavior when typed in from the keyboard in interpret state is not defined. (I've used Forth systems where you can have 5 >R in the input stream and it just works, and doesn't crash provided you do R> before the end of the line, or the end of the block. But the standard makes no guarantee whatsoever.)
So when >R is a word with default compilation behavior (but nondefault
interpret behavior, its *execute* behavior is what's defined), then a
synonym will work provided that it compiles the execution token of >R .
A synonym that simply has default compilation behavior won't work
because its own execution token will be compiled instead of >R's
execution token. But anything you do that gets it to compile >R's
execution token will work for a synonym of >R .
But if we replace a default-compilation-behavior >R with a
nondefault-compilation-behavior synonym, then what happens if we get
the xt of the synonym and execute it? Well, this is turning kind of
murky, what happens if you get the xt of >R and execute that? I don't
think it's guaranteed to have an xt you can use. I'm not clear whether
there's a problem here.
You could use things under-the-hood to implement SYNONYM nonportably.
Like, if >R calls a primitive, it's no big deal to get synonyms to call
the same primitive. Problem solved, nonportably.
If you can get the compiler to somehow look at MY>R and compile the xt
for >R without MY>R having to be immediate, then that should solve it
too. And I thought your dual-wordlist system would do that.
> One significant use of SYNONYM/ALIAS is to put the same name in
> several wordlists.
I didn't think of that!
If your wordlists are made with hash tables, is there any reason the
same word can't go into multiple wordlists? Copy your hash wherever you
like, the first one that gets searched and finds it will report back.
But that can't work for wordlists implemented as linked lists. You can
link to a word as many times as you like, but the word itself will only
link to one continuing list.
So we must restrict what we do with modern systems so we can cater to
old or minimal systems -- and the minimal ones probably will have
little need for SYNONYM anyway.
Albert van der Horst
<mli...@gmail.com> wrote:
>
>Albert van der Horst wrote:
>
>> Instead of concentrating on how to implement SYNONYM
>> I would like to see a careful unambiguous statement about
>> how it supposed to work.
>
Exactly what I ment.
>
>> By the way I hate this word. This would be the first definition
>> in the standard where parsing is done beyond the next word.
>
>\ parses to the end of the line. (( parses until it reaches a )) or end
: \ ^J WORD DROP ;
One word in my book. But I admit that I was exaggerating.
Maybe I should have said inhomogeneous parsing.
Besides there is no precedent for a defining word where the new
name does not follow the defining word immediately.
I will take the trouble to vote on this one.
<More implementation details snipped>
J Thomas
Albert van der Horst wrote:
> Besides there is no precedent for a defining word where the new
> name does not follow the defining word immediately.
If you have a standard input buffer, that isn't at all a big deal.
>in @ bl word drop >in @
Now you can parse either word as many times as you like. Just do DUP
>IN ! or OVER >IN ! and bob's your uncle.
I tend to admire Forths that do without an input buffer. But they
aren't standard and can't be standard unless the standard changes a
whole lot.
Anyway, SYNONYM is defined so the new name does follow the defining
word immediately. That's one of the things some people don't like,
they'd rather the old name came first. That fits a lot of things in
Forth. With MOVE the old address comes first, etc.
Ed
"Marcel Hendrix" <m...@iae.nl> wrote in message news:0633142...@frunobulax.edu...
> "Ed" <nos...@invalid.com> writes Re: RfD: SYNONYM
> [..]
> > I also have concerns with the name. Given its frequency
> > SYNONYM is far too long to type (and a horror to spell :)
> > Can we do better?
>
> "Given its frequency?" I have counted occurrences of ALIAS, AKA and
> SYNONYM in all the files (over 7,000 in total) I have for SwiftForth
> (80), VFX (5), Win32Forth (47), gForth (13) and iForth (0). (There
> are more references, but that's in documentation and defining the
> words themselves.)
Maybe I should have said "popularity for" an alias creating word :)
Like it not AKA ALIAS SYNONYM et al. are here to stay. People
keep using and wanting them so I guess there must be a need.
> In many cases I saw, it seems that doing : bar ... ; : foo bar ;
> would be perfectly adequate as bar has no special characteristics
> and foo is not time-critical.
That's what's wrong with it. Header-only aliases don't cost anything
- either in performance or code space. Aliases are a cleaner solution
than colon defs will even be.
> I'm not against standardizing this word; it is obviously in use
> by many Forths with conflicting names. But I am curious what's so
> fascinating about this word?
>
> I will always need to look up the documentation for SYNONYM, is
> it <oldword> <newword> or the reverse?
As with anything once it's standardized people get used to it and
the old forms vanish from memory as if they never existed.
Who still accidentally types EXPECT instead of ACCEPT ?
Probably no-one.
> Clearer would be :SYNONYM <newname> <oldname> SYNONYM; or
> :SYNONYM <newname> <oldname> ;
But an alias is *not* a colon definition and therefore should not appear
as one, IMO. Colon defs serve a very different purpose. Unlike aliases,
colon defs are designed to *replace* existing words.
It's *because* SYNONYM uses the same argument order as colon
defs that it creates all problems of having to hide/reveal as I indicated
earlier.
Alias creation words are actually more akin to CONSTANT VALUE etc
in that they look up an existing parameter (in this case a name or xt )
and build a new word with it. e.g. ALIAS is much easier to define than
SYNONYM because it has the right argument order to begin with.
Andreas Kochenburger
<m...@intranetsys.com> wrote:
>I find it simpler to reserve 2 extra bits in each header, an
>interpretation bit, a compilation bit, in addition to the traditional
>precedence (i.e. immediate) bit.
But you need one extra header per each semantic variant. Right?
Andreas
-------
1 + 1 = 3, for large values of 1.
Mark W. Humphries
> On 25 Aug 2006 18:47:59 -0700, "Mark W. Humphries"
> <m...@intranetsys.com> wrote:
> >I find it simpler to reserve 2 extra bits in each header, an
> >interpretation bit, a compilation bit, in addition to the traditional
> >precedence (i.e. immediate) bit.
>
> But you need one extra header per each semantic variant. Right?
Only for the very rare instances that I want a non-standard combination
of compilation and interpretation semantics. Usually to avoid needing
bracket names such as [IF] and ["]. The only bracketed words I use are
['] and [C']
Cheers,
Mark Humphries
Manila, Philippines
J Thomas
> > In many cases I saw, it seems that doing : bar ... ; : foo bar ;
> > would be perfectly adequate as bar has no special characteristics
> > and foo is not time-critical.
> That's what's wrong with it. Header-only aliases don't cost anything
> - either in performance or code space. Aliases are a cleaner solution
> than colon defs will even be.
And given the wide variety of systems -- indirect threading, direct
threading, subroutine jump etc, we don't have anything standardised to
do that. And there's something about this that keeps on getting in
people's way. It's an itch we can't scratch, and it keeps on causing
irritation. We run up against it from different directions and get
bothered about it each time.
Traditionally Forth let you do anything. You could make whatever you
wanted. To do it portably the implementation details have to be hidden
and you can only work around them, and a lot of things that are easy to
do on one single system turn into complicated workarounds. It's mostly
things that are easy to avoid in commercial code, but they keep on
itching.
When people came up with POSTPONE it was supposed to work seamlessly.
You wouldn't need to know whether a word was immediate or not, you
could just use it. You could make a new version of any word that would
look to a standard program like it was just doing what it always did,
but which actually did something extra.
As a trivial example, you could count the number of times you use DUP
in a program by redefining it.
VARIABLE #dups 0 #dups !
: DUP 1 #dups +! state @ if postpone dup else dup then ; IMMEDIATE
What if you POSTPONE DUP in the code itself? Then it does the right
thing. Whenever the defining word that DUP is postponed into executes
during compilation it compiles another DUP and it increments the count.
And a word that includes POSTPONE DUP will only be used during
compilation.
But it maybe-fails when you set up a jump table that includes the xt of
DUP and executes it. You'll get the special version, and you'll
increment the counter every time. That might be what you want this
time, but often it isn't.
The problem is that originally it was done too simply. We were proud of
how simple the interpreter/compiler was. If you're interpreting,
execute the xt. If you're compiling, check whether it's immediate and
if so execute it, otherwise compile it. If you can't find an xt, check
whether it's a number. That's all. The words themselves do everything
else.
But really we were making words that extended the compiler. And most of
the time, compiler extensions are useless when you're interpreting. If
I had to choose between compiler words that only extend the compiler
versus immediate words that do the same thing compiling or
interpreting, I'd take the compiler words. There are more of them.
There are only a handful of words like ( that work well doing the same
thing either way, and those can be defined twice.
IMMEDIATE was not a good choice. It seemed like a simplification to
ignore whether you were compiling or not. And it is a simplification
for people who want to get quick results without learning the language.
For them a statesmart ' CHAR DO etc are good. It doesn't matter to them
that an interpreted DO loop might be implemented entirely differently
from compiled DO . They can just use it and get their results.
But now we have endless complication. Try to do something trivial like
SYNONYM which will be a 5-minute one-liner on almost any individual
system once you know the details of how that system works, and we get
special case after special case. Forth programmers who don't like
standards laugh. Bitterly.
In practice my rule of thumb is, almost every immediate word is really
compile-only. And every word that postpones an immediate word is also
compile-only. Don't ever execute them while interpreting, and if you've
stored their xt's then don't execute the xt's while interpreting. When
I follow that rule almost all the wierd conditions go away. But I don't
know how to make SYNONYM follow that rule.
> It's *because* SYNONYM uses the same argument order as colon
> defs that it creates all problems of having to hide/reveal as I indicated
> earlier.
I keep repeating that this is a minor parsing problem, you don't have
to hide/reveal. Just grab the second name first and do whatever you
want to it. Then grab the first name and use that. Then parse from
beyond those names. Do whatever feels best for the word order. I like
the oldname first but it isn't real important.
J Thomas
Ed wrote:
> > In many cases I saw, it seems that doing : bar ... ; : foo bar ;
> > would be perfectly adequate as bar has no special characteristics
> > and foo is not time-critical.
> That's what's wrong with it. Header-only aliases don't cost anything
> - either in performance or code space. Aliases are a cleaner solution
> than colon defs will even be.
Suppose there was a way to standardise the part that factors out here.
There's some kind of implmentation specific magic that goes on at the
start of every word. At least a litle scrap of machine code somewhere,
that says what to do. Suppose you could somehow put the addresses
needed for that, plus instructions about how to use them, on the stack
so another command could use them. Would that be worth doing?
SYNONYM would use those to make new words with exactly the same
behavior as old words.
DOES> would use them to add a :NONAME's action to a CREATEd word.
Where else would it be useful? Could it be used to do tail-recursion?
It might go something like
@MAGIC ( xt -- magic ) get the implementation-specific data needed
to efficiently re-create this word's initiation and leave it on the
stack. The number of stack items left may vary for different words even
within one implementation.
,MAGIC ( magic -- ) Extend the last-defined word to efficiently
perform the actions of the magicked word, and then return.
This seems real limited, and I'm not getting a clear idea how it would
work. On some systems there's so little resemblance between fixing
headers, DOES> and tail-recursion that putting them together would make
a complicated chimera. Is there any way to turn this into something
that would be useful for more than a very few cases?
Ed
"J Thomas" <jeth...@gmail.com> wrote in message news:1156767371.3...@m73g2000cwd.googlegroups.com...
> Ed wrote:
>
> > > In many cases I saw, it seems that doing : bar ... ; : foo bar ;
> > > would be perfectly adequate as bar has no special characteristics
> > > and foo is not time-critical.
>
> > That's what's wrong with it. Header-only aliases don't cost anything
> > - either in performance or code space. Aliases are a cleaner solution
> > than colon defs will even be.
>
> And given the wide variety of systems -- indirect threading, direct
> threading, subroutine jump etc, we don't have anything standardised to
> do that. And there's something about this that keeps on getting in
> people's way. It's an itch we can't scratch, and it keeps on causing
> irritation. We run up against it from different directions and get
> bothered about it each time.
I don't think the real argument is whether or not forth should have
aliases. As you say, clearly there's an itch for it.
What we're seeing here is the politics of which version gets up!
> > It's *because* SYNONYM uses the same argument order as colon
> > defs that it creates all problems of having to hide/reveal as I indicated
> > earlier.
>
> I keep repeating that this is a minor parsing problem, you don't have
> to hide/reveal. Just grab the second name first and do whatever you
> want to it. Then grab the first name and use that. Then parse from
> beyond those names. Do whatever feels best for the word order. I like
> the oldname first but it isn't real important.
I'm afraid it is important :)
The alternative is equivalent to performing a needless SWAP
- albeit far more messy. Get the argument order right in the first
place and all work-arounds drop away.
Forth is supposed to be efficient both in concept and execution.
Since the three alias forms in common use all have issues to a
greater or lesser extent, I see this as the perfect opportunity to
"get it right". Bad practice should not be promoted. It was not
on a whim that I added the tagline:
> "Common practice" is not necessarily "best practice".
A Forth Standard ought to be technically unassailable.
Ed
"Neal Bridges" <nbri...@interlog.com> wrote in message news:12f2d9r...@corp.supernews.com...
Tradition and usage would indicate that aliases don't need to duplicate
every aspect of a word. Executing the alias name (and perhaps its tick)
and getting the same results appears to be the primary need.
This has allowed aliases to be implemented in a variety of ways. The
"ambiguous conditions" simply reflect that fact. They warn the user
not to dig deeply inside the innards of an alias and expect to see the
original word! That's reasonable, IMO.
The common form of ALIAS doesn't duplicate the flags for the reason
they may want to make a non-immediate alias from an immediate word.
Dubious as it may be, that feature is lost to your ALIAS since you
duplicate all flags.
I don't understand the "double forward parsing" complaints. All alias
creation involves parsing two names at some point. Even with ALIAS
the 'xt' had to come from somewhere!
BTW in your ALIAS there's no necessity to have an xt at all. You
could just as easily have implemented:
ALIAS <oldname> <newname>
Syntax is shorter and to the point. It's as easy as : ALIAS ' ALIAS ;
J Thomas
> > And given the wide variety of systems -- indirect threading, direct
> > threading, subroutine jump etc, we don't have anything standardised to
> > do that. And there's something about this that keeps on getting in
> > people's way. It's an itch we can't scratch, and it keeps on causing
> > irritation. We run up against it from different directions and get
> > bothered about it each time.
> I don't think the real argument is whether or not forth should have
> aliases. As you say, clearly there's an itch for it.
> What we're seeing here is the politics of which version gets up!
If you could write both versions portably, then the main point of
standardising them would be to make sure people don't give the same
name to two different versions that behave differently.
We could have a SYNONYM and an ALIAS both. It wouldn't be any big deal.
The reason it turns into a standards issue is that it's hard to write a
truly portable version.
George Hubert's approach is the closest I've seen for SYNONYM
: SYNONYM ( S: "newname" "oldname" -- )
:
BL WORD FIND >R COMPILE, POSTPONE ;
R> 1 = IF IMMEDIATE THEN ;;
I tentatively believe that this should work for everything except >R R@
R> 2>R 2R@ 2R> and UNLOOP .If you had a standard way to do
tail-recursion you could make it work on those too.
Similarly for ALIAS .
: ALIAS ( S: xt -1|1 "name" -- )
2>R :
R> COMPILE, POSTPONE ;
R>n 1 = IF IMMEDIATE THEN ;
With just the xt a standard program can't even tell whether the word
should be immediate, but add that in and it works as well as SYNONYM .
> > I keep repeating that this is a minor parsing problem, you don't have
> > to hide/reveal.
> I'm afraid it is important :)
>
> The alternative is equivalent to performing a needless SWAP
> - albeit far more messy. Get the argument order right in the first
> place and all work-arounds drop away.
Note that in my SYNONYM example the newword is used first.
Implementation efficiency is hard to prejudge when you span over all
standard systems.
GerryJ
> I also have concerns with the name. Given its frequency
> SYNONYM is far too long to type (and a horror to spell :)
> Can we do better?
>
But you can do
SYNONYM newname SYNONYM
Alternatively English always has another word, how about YCLEPT, that
will even baffle most native English speakers and put everyone at the
same disadvantage :-)
Gerry
David N. Williams
> [...]
>
> Note that in my SYNONYM example the newword is used first.
> Implementation efficiency is hard to prejudge when you span over all
> standard systems.
What about SYNONYM: ?
SYNONYM: newname oldname
That would disambiguate the order of arguments for me.
I like Anton's NEW-OLD suggestion, but would probably like
SYNONYM: about as well.
-- David
George Hubert
If oldname is immediate it has to be
vocabulary vnew
also vnew definitions
: newname postpone oldname ; immediate
previous definitions
so the user has to know whether oldname is or isn't immediate.
Basically that's
the bit of carnal knowledge that SYNONYM contains (it probably uses
FIND rather
than ' to look-up the word).
> --
> Regards
> Alex McDonald
Alex McDonald
Having given this abut 10 nanoseconds thought, will this work
transparently;
: newname [compile] oldname ; immediate
--
Regards
Alex McDonald
George Hubert
J Thomas wrote:
>
> > It's *because* SYNONYM uses the same argument order as colon
> > defs that it creates all problems of having to hide/reveal as I indicated
> > earlier.
>
> I keep repeating that this is a minor parsing problem, you don't have
> to hide/reveal. Just grab the second name first and do whatever you
> want to it. Then grab the first name and use that. Then parse from
> beyond those names. Do whatever feels best for the word order. I like
> the oldname first but it isn't real important.
What's shorter
: SYNONYM
HEADER hide
DEFINED DUP ?MISSING
1 = IF IMMEDIATE THEN
CFAPTR! reveal ;
or
: SYNONYM
>IN @ >R BL WORD DROP
DEFINED DUP ?MISSING
1 = IF IMMEDIATE THEN
R> >IN ! HEADER
BL WORD DROP CFAPTR! ;
I apologise for posting non-ANSI (i.e. Win32Forth specific) code
but the first is simpler IMO.
George Hubert
J Thomas
George Hubert wrote:
> What's shorter
>
> : SYNONYM
> HEADER hide
> DEFINED DUP ?MISSING
> 1 = IF IMMEDIATE THEN
> CFAPTR! reveal ;
>
> or
>
> : SYNONYM
> >IN @ >R BL WORD DROP
> DEFINED DUP ?MISSING
> 1 = IF IMMEDIATE THEN
> R> >IN ! HEADER
> BL WORD DROP CFAPTR! ;
The short way is shorter.
If I read it right, you do better with SYNONYM newname oldname. I think
this is in fact the way it's heading. I think you're winning at the
moment.
I like to do things the shorter simpler easier more-efficient way too.
What I've noticed with standards efforts though, is that it's a whole
lot harder to get a bunch of people to agree on something than it is to
write code. Already I'm sure you've spent more effort arguing which
order the words should go than it took you to implement it both ways.
SYNONYM is not likely to get used so much that being a little slower
will make a big difference. And if you're strapped for space to the
point that having SYNONYM a ilttle bigger is an issue, then you'd
probably do better to get busy with a text editor and global replace to
remove the need for SYNONYM and then you can remove SYNONYM too.
So my thought is, if I can do it either way without a big effort, I'll
let other people argue it out and go along with whatever they say -- or
else make my own nonstandard word and do it my way. LIfe is too short.
It's hard enough getting a standard that isn't crippled, I don't have
time to get upset about the small stuff.
J Thomas
Alex McDonald wrote:
> Having given this abut 10 nanoseconds thought, will this work
> transparently;
>
> : newname [compile] oldname ; immediate
That's very concise, I like it.
I think it will have trouble for non-immediate words that are getting
compiled.
: MYDUP [compile] dup ; immediate is just like
: MYDUP dup ; immediate
: test mydup ;
should give an error because it does the same thing as
: test [ dup ] ;
I think it will do exactly the right thing for compiler words. And it
would do the right thing for most normal words if there was a way to
make it immediate only when it ought to be.
Albert van der Horst
J Thomas <jeth...@gmail.com> wrote:
>
>Albert van der Horst wrote:
>
>> Besides there is no precedent for a defining word where the new
>> name does not follow the defining word immediately.
>
>If you have a standard input buffer, that isn't at all a big deal.
>
>>in @ bl word drop >in @
>
>Now you can parse either word as many times as you like. Just do DUP
>>IN ! or OVER >IN ! and bob's your uncle.
>
>I tend to admire Forths that do without an input buffer. But they
>aren't standard and can't be standard unless the standard changes a
>whole lot.
Please quote properly. I didn't write those manipulations
with >IN .
>
>Anyway, SYNONYM is defined so the new name does follow the defining
>word immediately. That's one of the things some people don't like,
>they'd rather the old name came first. That fits a lot of things in
>Forth. With MOVE the old address comes first, etc.
SYNONYM is not defined yet. Certainly not to a level that votes
could be taken to keep it out of the standard.
(Or get it in, what I don't expect.)
George Hubert
> If I read it right, you do better with SYNONYM newname oldname. I think
> this is in fact the way it's heading. I think you're winning at the
> moment.
>
No. SYNONYM has been in W32F for the last 10 yrs with the current
order. If a word with reversed names was added it should have a
different name. There's nothing stopping anyone proposing another word
with the opposite order or for ALIAS. Stephen suggested SYNONYM since
W32F and VXF both have it with the same order.
> I like to do things the shorter simpler easier more-efficient way too.
> What I've noticed with standards efforts though, is that it's a whole
> lot harder to get a bunch of people to agree on something than it is to
> write code. Already I'm sure you've spent more effort arguing which
> order the words should go than it took you to implement it both ways.
>
Where there are systems that use the same name for different though
similar functionality or different names for (nearly) the same
functionality there's always going to be a (possibly heated) debate on
the best name, functionality and what is or isn't an ambiguous
condition. Progrramming is certainly easier (unless you're
collaborating with others who want things done differently!).
> SYNONYM is not likely to get used so much that being a little slower
> will make a big difference. And if you're strapped for space to the
> point that having SYNONYM a ilttle bigger is an issue, then you'd
> probably do better to get busy with a text editor and global replace to
> remove the need for SYNONYM and then you can remove SYNONYM too.
>
Plus a program to locate all web-sites with downloadable W32F sources,
download, modify and upload them. Then of cause there's all the code on
individuals machines that might not even be connected to the web; how
is that done -;)
> So my thought is, if I can do it either way without a big effort, I'll
> let other people argue it out and go along with whatever they say -- or
> else make my own nonstandard word and do it my way. LIfe is too short.
> It's hard enough getting a standard that isn't crippled, I don't have
> time to get upset about the small stuff.
Then everyone does it their own way and we end up with portable way to
do it, so it can't be done in libraries. Everyone complains about not
enough portable code and libraries' yet when efforts are made to make
it easier they suggest not doing it and instead let everyone do it
their own way. Any system can have their own (possibly better on their
system) way (or extensions to the standard way) if they like, but still
support the standard way for compatibility and portability.
George Hubert
J Thomas
George Hubert wrote:
> > If I read it right, you do better with SYNONYM newname oldname. I think
> > this is in fact the way it's heading. I think you're winning at the
> > moment.
> No. SYNONYM has been in W32F for the last 10 yrs with the current
> order.
!! Then the standard should do it your way to avoid breaking existing
code.
Or if somebody else important has been doing SYNONYM with the other
word order, the standard should use a new name and not name it SYNONYM
with either order, since a standard SYNONYM would break code either
way.
Thank you for explaining. You put into an entirely different light.
George Hubert
Of course. Whatever names are added to the standard should not conflict
with existing names with different behaviour. FIELD has become FIELD:
for just that reason. If the only uses of a name all agree on the same
input/output argument order following word order etc. and functionality
(or are similar enough to be covered by reasonable ambiguous
conditions) then there's no problem; otherwise a new name that doesn't
cause conflicts has to be chosen. If an entirely new name results then
the exact functionality can be specified (hopefully w/o ambiguities;
they may result from implementation strategies anyway). The whole point
of the process is to avoid breaking existing code, while adding new
capabilities which programmers find useful. It doesn't stop anyone
providing more or different functionality; it's just that system
specific code won't be portable (unless an ANSI compatible harness is
provided).
George Hubert
David N. Williams
> J Thomas wrote:
>> George Hubert wrote:
>>>> If I read it right, you do better with SYNONYM newname oldname. I
think
>>>> this is in fact the way it's heading. I think you're winning at the
>>>> moment.
>>> No. SYNONYM has been in W32F for the last 10 yrs with the current
>>> order.
>> !! Then the standard should do it your way to avoid breaking existing
>> code.
>>
>> Or if somebody else important has been doing SYNONYM with the other
>> word order, the standard should use a new name and not name it SYNONYM
>> with either order, since a standard SYNONYM would break code either
>> way.
>>
>> Thank you for explaining. You put into an entirely different light.
>
> Of course. Whatever names are added to the standard should not conflict
> with existing names with different behaviour. FIELD has become FIELD:
As a data point, in pfe it's SYNONYM newname oldname.
-- David
J Thomas
David N. Williams wrote:
> As a data point, in pfe it's SYNONYM newname oldname.
OK, that's pfe and Win32F both with newname oldname.
Is there an implementation that uses oldname newname ?
Ed
"J Thomas" <jeth...@gmail.com> wrote in message news:1156962755.2...@m79g2000cwm.googlegroups.com...
AKA oldname newname
It's used by Forth Inc. and likely to be as old, if not older, than
SYNONYM and ALIAS. Apart from argument order the only
difference to SYNONYM is that it doesn't duplicate immediacy.
They almost got it right :)
Ed
"George Hubert" <george...@yahoo.co.uk> wrote in message
news:1156869158.5...@p79g2000cwp.googlegroups.com...
This is shorter...
: SYNONYM2 ( oldname newname )
DEFINED DUP ?MISSING
HEADER CFAPTR!
1 = IF IMMEDIATE THEN ;
(I haven't actually tried this but you get the idea)
Similarly shorter will be the ANS equivalent. If one already
has ALIAS then it's just...
: SYNONYM2 ( oldname newname )
BL WORD FIND TUCK 0= ABORT" not found"
ALIAS 1 = IF IMMEDIATE THEN ;
The <oldname> <newname> order is the most efficient and
therefore wins out every time.
As for remembering the syntax, one need only invent something to
jog the memory. Here are some possible names for the new function
and their interpretation:
COPY oldname as newname
DEFINE oldname as newname
ASSIGN oldname as newname
Note: the 'as' is not actually used - I include it here only to illustrate
the thinking behind the names.
George Hubert
If oldname exists create newname as a non-immediate word whose xt is 1
or -1 depending on the immediacy of oldname. That would crash when
executed, or when any word that compiles it executes. Either you need a
SWAP after ?MISSING or use TUCK instead of DUP.
>
> Similarly shorter will be the ANS equivalent. If one already
> has ALIAS then it's just...
>
> : SYNONYM2 ( oldname newname )
> BL WORD FIND TUCK 0= ABORT" not found"
> ALIAS 1 = IF IMMEDIATE THEN ;
>
BL WORD FIND can be replaced by DEFINED and 0= ABORT" not found" by
?MISSING since that's roughly what they do (except DEFINED uses a
version of FIND that precludes words of the form OBJECT.IVAR which
could cause problems while
?MISSING throws error -13).
> The <oldname> <newname> order is the most efficient and
> therefore wins out every time.
>
There's little in it either way. The newname oldname usage has been in
use for 10 yrs so W32F users are used to it.
> As for remembering the syntax, one need only invent something to
> jog the memory. Here are some possible names for the new function
> and their interpretation:
>
> COPY oldname as newname
> DEFINE oldname as newname
> ASSIGN oldname as newname
>
> Note: the 'as' is not actually used - I include it here only to illustrate
> the thinking behind the names.
Good! It would consume newname and make it a word that calls the
last-defined PROC since AS is alredy a word in W32F.
George Hubert
Ed
My untested code crashed. It should have been...
: SYNONYM2 ( oldname newname )
DEFINED DUP ?MISSING
HEADER
1 = IF IMMEDIATE THEN
CFAPTR! ;
> > Similarly shorter will be the ANS equivalent. If one already
> > has ALIAS then it's just...
> >
> > : SYNONYM2 ( oldname newname )
> > BL WORD FIND TUCK 0= ABORT" not found"
> > ALIAS 1 = IF IMMEDIATE THEN ;
> >
>
> BL WORD FIND can be replaced by DEFINED and 0= ABORT" not found" by
> ?MISSING since that's roughly what they do (except DEFINED uses a
> version of FIND that precludes words of the form OBJECT.IVAR which
> could cause problems while
> ?MISSING throws error -13).
The code was meant as a generic example to show those who had
ALIAS how easily the "reverse" SYNONYM could be defined.
Specific implementations may be able to reduce code size further.
> > The <oldname> <newname> order is the most efficient and
> > therefore wins out every time.
> >
>
> There's little in it either way. The newname oldname usage has been in
> use for 10 yrs so W32F users are used to it.
Forth Inc. users will have had 10 yrs or more with "oldname newname".
But I'm not sure that matters.
It depends where forth is headed. Is it looking to the future or to the
past? Does technical excellence still have any relevance? Forth used
to be about getting best possible outcomes. Maybe all that has changed?
> > As for remembering the syntax, one need only invent something to
> > jog the memory. Here are some possible names for the new function
> > and their interpretation:
> >
> > COPY oldname as newname
> > DEFINE oldname as newname
> > ASSIGN oldname as newname
> >
> > Note: the 'as' is not actually used - I include it here only to illustrate
> > the thinking behind the names.
>
> Good! It would consume newname and make it a word that calls the
> last-defined PROC since AS is alredy a word in W32F.
To clarify - there is no word 'as'. The 'as' above was intended to give
readers a feeling for what the function does. In use, it is simply:
COPY oldname newname
DEFINE oldname newname
ASSIGN oldname newname
J Thomas
> > There's little in it either way. The newname oldname usage has been in
> > use for 10 yrs so W32F users are used to it.
>
> Forth Inc. users will have had 10 yrs or more with "oldname newname".
> But I'm not sure that matters.
Do they have that experience using the name SYNONYM and the "oldname
newname" syntax?
If so, we must not use the name SYNONYM in a standard.
If not, we can look at declaring the name AKA or whatever with "oldname
newname" syntax and SYNONYM with "newname oldname" syntax, and then
make one or both of them standard.
> It depends where forth is headed. Is it looking to the future or to the
> past? Does technical excellence still have any relevance? Forth used
> to be about getting best possible outcomes. Maybe all that has changed?
Just suppose that the standard does it the way you don't like. Then you
have a choice.
You can ignore the standard.
Or you can write a short routine that implements it the way you don't
like. That will probably not be as elegant on your system as the way
you do like it, but there's only one time you need to use it -- when
you import code that does it the standard way. Or you might choose to
use that routine when you write code to give to others. If you want you
can write it your way first and get everything working, and then go
back and change all the ALIASes to SYNONYMs and switch the names
around. Test it with the inefficient version to make sure it works.
Or you can write a routine that will go through sourcecode and change
the source. When you import source code you switch SYNONYM to ALIAS and
swap the next two words. When you export source code you do the
reverse. There's room for trouble when the code does POSTPONE SYNONYM
etc, but I hope that sort of thing will be rare. If you think it will
be a problem you can test for it. This way you get the best of both
worlds even though the standard didn't go your way. You can use optimal
code on your system, and you can still import and export standard code.
Different Forth implementors have optimised different things. If we
want code to run on lots of systems we're going to have to sacrifice
some optimality somewhere, sometimes. Maybe one result of comparing all
these different systems is to factor some behaviors that will result in
more flexibility everywhere the new way is implemented. That would be a
good outcome.
Albert van der Horst
Ed <nos...@invalid.com> wrote:
<SNIP>
>The <oldname> <newname> order is the most efficient and
>therefore wins out every time.
I don't care about efficiency. So I don't follow you.
<SNIP>
Andreas Kochenburger
>It depends where forth is headed. Is it looking to the future or to the
>past? Does technical excellence still have any relevance? Forth used
>to be about getting best possible outcomes. Maybe all that has changed?
I asked my magic glass ball and it revealed the future:
"As long as there are small systems with restricted resources and
processors with a von-Neumann architecture around, Forth will "stay
alive" and be as useful as a Swiss army knife."
Alas the rest was hidden beneath the black clouds stirred up by
trouble and dissent among the followers and disbelievers in c.l.f.
Andreas
-------
1 + 1 = 3, for large values of 1.
Stephen Pelc
>It depends where forth is headed. Is it looking to the future or to the
>past? Does technical excellence still have any relevance? Forth used
>to be about getting best possible outcomes. Maybe all that has changed?
SYNONYM <new> <old> exists because it enables some systems,
especially cross compilers, to do "stuff" that cannot be done
from an xt. Yes, RENAME-WORD <old> <new> could exist. The reason
to choose SYNONYM is simply that it has *usage* in W32F, MPE
cross compilers, VFX Forth and PFE over 10 years or so.
The new/old order is a trivial one, and I could find no common
practice for it.
I really don't see that disenfranchising cross compilers for
small systems is a sign of technical excellence.
Stephen
--
Stephen Pelc, steph...@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
Ed
"Stephen Pelc" <steph...@mpeforth.com> wrote in message news:44f75b06...@news.demon.co.uk...
> On Thu, 31 Aug 2006 23:08:30 +1000, "Ed" <nos...@invalid.com> wrote:
>
> >It depends where forth is headed. Is it looking to the future or to the
> >past? Does technical excellence still have any relevance? Forth used
> >to be about getting best possible outcomes. Maybe all that has changed?
>
> SYNONYM <new> <old> exists because it enables some systems,
> especially cross compilers, to do "stuff" that cannot be done
> from an xt. Yes, RENAME-WORD <old> <new> could exist. The reason
> to choose SYNONYM is simply that it has *usage* in W32F, MPE
> cross compilers, VFX Forth and PFE over 10 years or so.
>
> The new/old order is a trivial one, and I could find no common
> practice for it.
>
> I really don't see that disenfranchising cross compilers for
> small systems is a sign of technical excellence.
AKA will also have a considerable user base. Presumably Forth Inc
also makes cross compilers for small systems. If SYNONYM is
adopted then those users would be disenfranchised.
All three forms of alias in common use have defects. I don't see
what technical excellence is to be had in choosing one [bad] form
and imposing it on users of the other two. That will certainly
disenfranchise people. Opinion may vary but that's mine.
Good luck.
George Hubert
Ed wrote:
> "Stephen Pelc" <steph...@mpeforth.com> wrote in message news:44f75b06...@news.demon.co.uk...
> > On Thu, 31 Aug 2006 23:08:30 +1000, "Ed" <nos...@invalid.com> wrote:
> >
> > >It depends where forth is headed. Is it looking to the future or to the
> > >past? Does technical excellence still have any relevance? Forth used
> > >to be about getting best possible outcomes. Maybe all that has changed?
> >
> > SYNONYM <new> <old> exists because it enables some systems,
> > especially cross compilers, to do "stuff" that cannot be done
> > from an xt. Yes, RENAME-WORD <old> <new> could exist. The reason
> > to choose SYNONYM is simply that it has *usage* in W32F, MPE
> > cross compilers, VFX Forth and PFE over 10 years or so.
> >
> > The new/old order is a trivial one, and I could find no common
> > practice for it.
> >
> > I really don't see that disenfranchising cross compilers for
> > small systems is a sign of technical excellence.
>
> AKA will also have a considerable user base. Presumably Forth Inc
> also makes cross compilers for small systems. If SYNONYM is
> adopted then those users would be disenfranchised.
>
Isn't the problem with AKA that some Forths have versions that
make newname immdiate when oldname is whereas others always
make newname non-immediate, so standardising it (with that name)
would cause problems. No-one is saying Forths that have it can't
continue supplying their version with their Forth.
> All three forms of alias in common use have defects. I don't see
> what technical excellence is to be had in choosing one [bad] form
> and imposing it on users of the other two. That will certainly
> disenfranchise people. Opinion may vary but that's mine.
>
IMO most Forths have 1 (or more; Win32Forth supports both ALIAS
and SYNONYM since there are times when 1 or the other is the best
choice) so there's clearly a need for some way to create aliases (and
IMO we want to avoid a cludgy solution like locals). Perhaps
standardising both ALIAS (for words with default compilation semantics
and occasions where xt isn't derived from a name) and SYNONYM
(or another name with reversed order of newname and oldname that
inherits immediacy/special compilation semantics)
George Hubert
Anton Ertl
[synonym of >r]
>A synonym that simply has default compilation behavior won't work
>because its own execution token will be compiled instead of >R's
>execution token.
A synonym (as proposed) of >R would have the same compilation
semantics as >R. In order to work correctly with [COMPILE], that
would have to be its default compilation semantics, just as for >R (at
least as defined in the standard document; I guess that nobody has
tested "[COMPILE] >R" in a standard program).
>But if we replace a default-compilation-behavior >R with a
>nondefault-compilation-behavior synonym, then what happens if we get
>the xt of the synonym and execute it? Well, this is turning kind of
>murky, what happens if you get the xt of >R and execute that? I don't
>think it's guaranteed to have an xt you can use.
I once asked the TC about ticking EXIT, and got an informal answer
that it is non-standard because EXIT has no interpretation semantics.
The same would apply to >R and friends.
>You could use things under-the-hood to implement SYNONYM nonportably.
>Like, if >R calls a primitive, it's no big deal to get synonyms to call
>the same primitive. Problem solved, nonportably.
Yes, that's what I would expect SYNONYM to do.
>If your wordlists are made with hash tables, is there any reason the
>same word can't go into multiple wordlists? Copy your hash wherever you
>like, the first one that gets searched and finds it will report back.
>But that can't work for wordlists implemented as linked lists. You can
>link to a word as many times as you like, but the word itself will only
>link to one continuing list.
You lost me here. Hmm, are you thinking of having only one header for
SYNONYMs that happen to have the same name. While you could probably
design a data structure that supported this, I doubt that any current
Forth uses such a data structure. And it's probably not worth the
complication to implement such a data structure.
In Gforth, we use hash tables and linked lists. Every word gets its
own header, even if it is a synonym and happens to have the same name
as some other word (in some other wordlist).
- 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 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
George Hubert
Anton Ertl wrote:
> "J Thomas" <jeth...@gmail.com> writes:
>
> You lost me here. Hmm, are you thinking of having only one header for
> SYNONYMs that happen to have the same name. While you could probably
> design a data structure that supported this, I doubt that any current
> Forth uses such a data structure. And it's probably not worth the
> complication to implement such a data structure.
>
Actually Win32Forth classes all contain an embedded wordlist, which
always
contains all the words from it's super-class; it does this by copying
all the heads
of the lists to the new wordlist, rather than initialising them to zero
(or whatever
other terminating value is used). Of course it's an all or nothing
technique; you can
only have all the words (or none by initialising to the terminator),
but enables words
to be internal to a class and it's descendants while being hidden the
rest of the time.
> In Gforth, we use hash tables and linked lists. Every word gets its
> own header, even if it is a synonym and happens to have the same name
> as some other word (in some other wordlist).
>
Apart from inheritance in classes that's how W32F does it. Synonyms
have a separate header that points to the same xt.
George Hubert
ward mcfarland
how about CLONE as the verb to create a word with a new name or
wordlist, but identical behavior otherwise (all semantics, includin
immediacy) ?
Stephen Pelc
wrote:
SYNONYM does not have name conflicts. The name was selected some time
ago to avoid them. Which current implementation uses SYNONYM with
a specification that is different to the proposed one?
AKA and ALIAS had various usage, stack effect and semantic conflicts
among systems. A new name had to be found.
I have no objections to CLONE <old> <new> but see no reason to
standardise it.
ward mcfarland
> AKA and ALIAS had various usage, stack effect and semantic conflicts
> among systems. A new name had to be found.
I got a bit lost in this rather convoluted thread, but I thought someone
did cite a SYNONYM that did not duplicate all possible behaviors. If
not, then SYNONYM is the best choice.
-- w