>ORDER ORDER> ORDER@
David N. Williams
discussion, I've put this reply in a new thread. It was tedious
to look up the origin of the names in the subject line, because
Google ignores ">", "<", and "@".
On 1/21/10 2:52 PM, J Thomas wrote:
> [...]
>
> I find that I mostly use WORDLIST in place of VOCABULARY . It works OK.
> I don't lose much. There are some words that would probably make it a
> little easier, for example something to do
>
> GET-ORDER wordlist SWAP 1+ SET-ORDER
>
> etc with a single command. I haven't seen a proposal for names for those
> words, and if we did get them standardised I would quit using what I
use now
> and I'd use the new names. I don't need VOCABULARY but if I wanted to use
> it my code would be as portable as it ever was.
Aside from whether it needs a name, the above has a natural
factorization:
wordlist >order
I used to use TO-ORDER instead of >ORDER, but was utterly
convinced by Michael Gassanenko's naming for the trio:
[UNDEFINED] >order [IF]
: >order ( wid -- order: wid )
>r get-order r> swap 1+ set-order ; [THEN]
[UNDEFINED] order> [IF]
: order> ( order: wid -- s: wid )
get-order swap >r 1- set-order r> ; [THEN]
[UNDEFINED] order@ [IF]
: order@ ( order: wid -- s: wid )
get-order over >r 0 ?DO drop LOOP r> ; [THEN]
\ mlg's definition:
\ : ORDER@ ( -- wid ) ORDER> DUP >ORDER ;
The affectation of conditional definition is my political
statement that if the words aren't common practice they ought to
be. :-)
-- David
See:
From: "Michael L.Gassanenko" <m_l...@yahoo.com>
Newsgroups: comp.lang.forth
Subject: Re: namespace /was: Simple named structures
Date: Tue, 03 Sep 2002 23:26:00 +0400
WATCH OUT FOR LINEWRAP
http://groups.google.com/group/comp.lang.forth/msg/1acf150d2b29f551?hl=en
Coos Haak
There was common practice for the last word: CONTEXT @
Or as an analogue to GET-CURRENT: GET-CONTEXT
Which is what I use for years now ;-)
> -- David
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Bruce McFarling
> Aside from whether it needs a name, the above has a natural
> factorization:
> wordlist >order
> I used to use TO-ORDER instead of >ORDER, but was utterly
> convinced by Michael Gassanenko's naming for the trio:
>
> [UNDEFINED] >order [IF]
> : >order ( wid -- order: wid )
> >r get-order r> swap 1+ set-order ; [THEN]
>
> [UNDEFINED] order> [IF]
> : order> ( order: wid -- s: wid )
> get-order swap >r 1- set-order r> ; [THEN]
>
> [UNDEFINED] order@ [IF]
> : order@ ( order: wid -- s: wid )
> get-order over >r 0 ?DO drop LOOP r> ; [THEN]
> \ mlg's definition:
> \ : ORDER@ ( -- wid ) ORDER> DUP >ORDER ;
In the dpANS appendix reference implentations, they use "drops"
for ...
: drops ( x1 ... xn n -- ) 0 ?DO DROP LOOP ;
: order@ ( order: wid -- wid )
GET-ORDER OVER >R DROPS R> ;
David N. Williams
> Op Fri, 22 Jan 2010 11:41:50 -0500 schreef David N. Williams:
>
>>
>> [UNDEFINED] order@ [IF]
>> : order@ ( order: wid -- s: wid )
>> get-order over>r 0 ?DO drop LOOP r> ; [THEN]
>> \ mlg's definition:
>> \ : ORDER@ ( -- wid ) ORDER> DUP>ORDER ;
>>
> There was common practice for the last word: CONTEXT @
> Or as an analogue to GET-CURRENT: GET-CONTEXT
> Which is what I use for years now ;-)
Yep, I'd just reminded myself that DPANS has no CONTEXT. :-)
-- David
Anton Ertl
>: >order ( wid -- order: wid )
> >r get-order r> swap 1+ set-order ; [THEN]
Gforth has had that since 0.5.0 (released in 2000). It's certainly
one thing I miss now and then in standard code, and just a week ago I
saw one of my students had written code that would have benefited from
>ORDER. I would welcome an RfD that proposes it.
>[UNDEFINED] order> [IF]
>: order> ( order: wid -- s: wid )
> get-order swap >r 1- set-order r> ; [THEN]
>
>[UNDEFINED] order@ [IF]
>: order@ ( order: wid -- s: wid )
> get-order over >r 0 ?DO drop LOOP r> ; [THEN]
I have never missed one of those.
PREVIOUS is what I use when I want to remove the top of the search
order.
CONTEXT would be a traditional word for accessing the top of the
search order (i.e., CONTEXT @ instead of ORDER@). Gforth has CONTEXT,
but we hardly use it and I don't miss it when I write a standard
program.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
David N. Williams
I hadn't run across that, but I do like the name DROPS better
than DISCARD, which I saw was used for the same thing in dpANS94
A.16.6.2.0715. DROPS looks like a good candidate for machine
code. It would be a really smart optimizer that would know to
replace the loop by a bumped stack pointer.
But then all three order stack words can be simple in machine
code.
-- David
David N. Williams
> "David N. Williams"<will...@umich.edu> writes:
>> :>order ( wid -- order: wid )
>> >r get-order r> swap 1+ set-order ; [THEN]
>
> Gforth has had that since 0.5.0 (released in 2000). It's certainly
> one thing I miss now and then in standard code, and just a week ago I
> saw one of my students had written code that would have benefited from
>> ORDER. I would welcome an RfD that proposes it.
So it predates my learning the name from Michael. Okay, I'll
give an RfD a shot. Does anybody know of conflicting common
practice?
>> [UNDEFINED] order> [IF]
>> : order> ( order: wid -- s: wid )
>> get-order swap>r 1- set-order r> ; [THEN]
>>
>> [UNDEFINED] order@ [IF]
>> : order@ ( order: wid -- s: wid )
>> get-order over>r 0 ?DO drop LOOP r> ; [THEN]
>
> I have never missed one of those.
I'm pretty sure I haven't missed them either. But given >ORDER,
I would advocate reserving their names.
> PREVIOUS is what I use when I want to remove the top of the search
> order.
Me, too.
> CONTEXT would be a traditional word for accessing the top of the
> search order (i.e., CONTEXT @ instead of ORDER@). Gforth has CONTEXT,
> but we hardly use it and I don't miss it when I write a standard
> program.
>
> - anton
-- David
J Thomas
> wordlist >order
>
> I used to use TO-ORDER instead of >ORDER, but was utterly convinced by
> Michael Gassanenko's naming for the trio:
> >order
> order>
> order@
Those look like excellent names to me.
Bee
> So as not to disrupt the intense "4th RfD: Directories"
> discussion, I've put this reply in a new thread. It was tedious
> to look up the origin of the names in the subject line, because
> Google ignores ">", "<", and "@".
>
> On 1/21/10 2:52 PM, J Thomas wrote:
> > [...]
> > I find that I mostly use WORDLIST in place of VOCABULARY . It works OK.
> > I don't lose much. There are some words that would probably make it a
> > little easier, for example something to do
> >
> > GET-ORDER wordlist SWAP 1+ SET-ORDER
These words add to the wordlist:
1) only if the new wordlist does not exist in the list
2) if the new wordlist already exists, it is moved to the top
This word _-ORDER is an internal factor:
: _-ORDER ( w wid*n n -- wid*n w n ) ( remove from search order )
DUP IF 1- SWAP >R ( >> ) RECURSE ( << ) ( wid*i w' n (R wid*j )
OVER R@ XOR IF 1+ R> -ROT EXIT THEN R> DROP
THEN ;
: -ORDER ( wid -- ) GET-ORDER _-ORDER NIP SET-ORDER ;
: +ORDER ( wid -- ) DUP >R -ORDER GET-ORDER R> SWAP 1+ SET-ORDER ;
--
Bill Muench
Santa Cruz, California
Bruce McFarling
> I hadn't run across that, but I do like the name DROPS better
> than DISCARD, which I saw was used for the same thing in dpANS94
> A.16.6.2.0715. DROPS looks like a good candidate for machine
> code. It would be a really smart optimizer that would know to
> replace the loop by a bumped stack pointer.
I must have seen DROPS in someone else's code and swapped it in for
the A.16.6.2.0715 code when I borrowed from it for []Niclos[].
Where you have an SP@ and SP! and know the direction of the stack (or
infer it ... if there's an SP@ you can find it out), there will be a
faster colon definition for DROPS ... and of course for the common
indexed stacks there will be a faster CODE definition.
OTOH, if you are using DROPS inside an inner loop, an even better way
to optimize it would be to rewrite the loop so you aren't doing that
anymore ... there ought to be a better way to go about it than
repeatedly putting some counted list on the stack and then erasing it.
Stephen Pelc
wrote:
>: -ORDER ( wid -- ) GET-ORDER _-ORDER NIP SET-ORDER ;
>: +ORDER ( wid -- ) DUP >R -ORDER GET-ORDER R> SWAP 1+ SET-ORDER ;
Recommended and already in several systems.
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
David N. Williams
> On Fri, 22 Jan 2010 13:14:33 -0800 (PST), Bee<200...@calcentral.com>
> wrote:
>
>> : -ORDER ( wid -- ) GET-ORDER _-ORDER NIP SET-ORDER ;
>> : +ORDER ( wid -- ) DUP>R -ORDER GET-ORDER R> SWAP 1+ SET-ORDER ;
>
> Recommended and already in several systems.
Clearly the potential glossary is growing. It's nice that
everything so far has a reference implementation. Any other
recommended words?
-- David
Bruce McFarling
> I used to use TO-ORDER instead of >ORDER, but was utterly
> convinced by Michael Gassanenko's naming for the trio:
> [UNDEFINED] >order [IF]
> : >order ( wid -- order: wid )
> >r get-order r> swap 1+ set-order ; [THEN]
> [UNDEFINED] order> [IF]
> : order> ( order: wid -- s: wid )
> get-order swap >r 1- set-order r> ; [THEN]
> [UNDEFINED] order@ [IF]
> : order@ ( order: wid -- s: wid )
> get-order over >r 0 ?DO drop LOOP r> ; [THEN]
> \ mlg's definition:
> \ : ORDER@ ( -- wid ) ORDER> DUP >ORDER ;
Looking through the definition of the preliminary []Niclos[] namespace
control words ...
... I did the equivalent of >ORDER once, but it was in defining []
Niclos[] itself, so I did not have any place to store words yet, so it
was in a DOES> in a nameless word executed after the
( xt ) WORDLIST CREATE []Niclos[] , EXECUTE
to apply the action to []Niclos[].
I never did order>, I did order@ once, and three times I did whatever
it is called to:
... >R GET-ORDER NIP R> SWAP SET-ORDER ...
... "replace-top-in-order" saying it out, but what would it be called
in the ORDER> >ORDER ORDER@ lexicon ... ORDER! perhaps?
Anton Ertl
>I never did order>, I did order@ once, and three times I did whatever
>it is called to:
>
>... >R GET-ORDER NIP R> SWAP SET-ORDER ...
>
>... "replace-top-in-order" saying it out, but what would it be called
>in the ORDER> >ORDER ORDER@ lexicon ... ORDER! perhaps?
I would call it PREVIOUS >ORDER, or traditionally CONTEXT !. Not sure
if it's used frequently enough to merit a separate word, but if you
have ORDER@, then ORDER! would be the logical name.
Bruce McFarling
wrote:
> Not sure if it's used frequently enough to merit a separate word,
> but if you have ORDER@, then ORDER! would be the logical name.
As I said, its used three times, and as a six word sequence performing
a coherent action, it'd merit factoring out if used once.
Anton Ertl
>On Jan 23, 7:57=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
After >ORDER (or CONTEXT), it's a 2-word sequence.
Bruce McFarling
wrote:
> After >ORDER (or CONTEXT), it's a 2-word sequence.
Yes, but I use ORDER! three times, and if I ever need >ORDER, its also
a two word sequence, "ALSO ORDER!".
CONTEXT cannot always be defined where standard search orders are
available, while ORDER@ and ORDER! can always be defined where
standard search orders are available.
Anton Ertl
>These words add to the wordlist:
>1) only if the new wordlist does not exist in the list
>2) if the new wordlist already exists, it is moved to the top
What's the point of such a word? The functionality is equivalent to
>ORDER, while one wants the additional wordlist in the search order.
Once you want to restore the former search order, there is a
difference between the words:
* With >ORDER, you use PREVIOUS
* With your word ("+ORDER"?), you are out of luck. There is no simple
way to restore the original search order. If you had saved it first
with with GET-ORDER, you could restore it with SET-ORDER.
So, what is the usage scenario of +ORDER, and why would you use it
instead of >ORDER?
Bee
wrote:
> Bee <200...@calcentral.com> writes:
> >These words add to the wordlist:
> >1) only if the new wordlist does not exist in the list
> >2) if the new wordlist already exists, it is moved to the top
>
> What's the point of such a word? The functionality is equivalent to >ORDER, while one wants the additional wordlist in the search order.
No... ALMOST equivalent, +ORDER and -ORDER remove duplicates from the
search order.
If you have something like:
wordlist1 wordlist2 wordlist3
then do:
wordlist2 >ORDER
result:
wordlist1 wordlist2 wordlist3 wordlist2
then do:
PREVIOUS
result:
wordlist1 wordlist2 wordlist3
you still have wordlist2 in the search order
OTOH if you have:
wordlist1 wordlist2 wordlist3 wordlist2
and do:
wordlist2 -ORDER
result:
wordlist1 wordlist3
That is very nice!
> Once you want to restore the former search order, there is a
> difference between the words:
>
> * With >ORDER, you use PREVIOUS
>
> * With your word ("+ORDER"?), you are out of luck. There is no simple
> way to restore the original search order. If you had saved it first
> with with GET-ORDER, you could restore it with SET-ORDER.
Its true... but I do NOT need luck.
I consider PREVIOUS and friends to be a workaround from the bad-old-
days of VOCABULARY.
: ONLY ( -- )( 16.6.2.1965 ) -1 SET-ORDER ;
: ALSO ( -- )( 16.6.2.0715 ) GET-ORDER OVER SWAP 1+ SET-ORDER ;
: PREVIOUS ( -- )( 16.6.2.2037 ) GET-ORDER NIP 1- SET-ORDER ;
> So, what is the usage scenario of +ORDER, and why would you use it
> instead of >ORDER?
! with +ORDER, I EXPLICITLY set... save... change... restore...
wordlists:
wordlist1 wordlist2 2 SET-ORDER
...
...
GET-ORDER ( wid*n n )
wordlist3 +ORDER
...
wordlist2 -ORDER
...
( wid*n n ) SET-ORDER
Anton Ertl
>On Jan 26, 10:16 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Bee <200...@calcentral.com> writes:
>> >These words add to the wordlist:
>> >1) only if the new wordlist does not exist in the list
>> >2) if the new wordlist already exists, it is moved to the top
>>
>> What's the point of such a word? The functionality is equivalent to >ORDER, while one wants the additional wordlist in the search order.
>No... ALMOST equivalent, +ORDER and -ORDER remove duplicates from the
>search order.
Which does not matter as long as you want the additional wordlist in
the search order. Every name resolves to the same word (or is not
found) either way. The only differences are in the result of
GET-ORDER and the output of ORDER.
>> Once you want to restore the former search order, there is a
>> difference between the words:
>>
>> * With >ORDER, you use PREVIOUS
>>
>> * With your word ("+ORDER"?), you are out of luck. There is no simple
>> way to restore the original search order. If you had saved it first
>> with with GET-ORDER, you could restore it with SET-ORDER.
>
>Its true... but I do NOT need luck.
>
>I consider PREVIOUS and friends to be a workaround from the bad-old-
>days of VOCABULARY.
PREVIOUS is not a workaround. It works for wordlists as well as for
VOCABULARYs, so we don't need a new name. A typical usage scenario
is: I want a wordlist W visible in a specific region. I do:
W >order \ the region starts here
... \ code that contains words from W
previous \ the region ends here
Nicely nestable. E.g., you can use that in a file that is later
INCLUDED by another file, and the other file does not need to save and
restore the search order around the INCLUDED.
>> So, what is the usage scenario of +ORDER, and why would you use it
>> instead of >ORDER?
>
>! with +ORDER, I EXPLICITLY set... save... change... restore...
>wordlists:
>
>wordlist1 wordlist2 2 SET-ORDER
>...
>...
>GET-ORDER ( wid*n n )
> wordlist3 +ORDER
> ...
> wordlist2 -ORDER
> ...
>( wid*n n ) SET-ORDER
If you do the GET-ORDER before the first SET-ORDER, you get the same
nesting properties, and more control over the search order, but at a
higher complexity.
And you won't be able to profit from, e.g., having a wordlist for
floored (or symmetric) division on top of the forth-wordlist, because
you originally developped on a floored (or symmetric) system, but the
system you want to run on does it the other way.
Also, if you control the search order to this degree, I don't see much
point in +ORDER and -ORDER. One could write the above as:
wordlist1 wordlist2 2 SET-ORDER
...
...
GET-ORDER ( wid*n n )
wordlist3 >ORDER
...
wordlist1 wordlist3 2 SET-ORDER
...
( wid*n n ) SET-ORDER
and it would be easier to follow what the actual search order is (and
the only case where these words make sense is if you know the complete
search order and also want to control it completely).
David N. Williams
> On 1/22/10 1:56 PM, Anton Ertl wrote:
> > "David N. Williams"<will...@umich.edu> writes:
> >> :>order ( wid -- order: wid )
> >> >r get-order r> swap 1+ set-order ; [THEN]
> >
> > Gforth has had that since 0.5.0 (released in 2000). It's certainly
> > one thing I miss now and then in standard code, and just a week ago I
> > saw one of my students had written code that would have benefited from
> >> ORDER. I would welcome an RfD that proposes it.
>
> So it predates my learning the name from Michael. Okay, I'll
> give an RfD a shot. Does anybody know of conflicting common
> practice?
I got delayed from working on stuff for a while; here's where
things are at the moment with the search-order words.
I'm doing things in reverse, namely, a reference implementation
and tests for now, with a more organized RfD planned to come a
bit later, RSN. I would post that to the forth200x list as well
as here.
The reference library is short, so it's also appended to the end
of this message:
http://www-personal.umich.edu/~williams/archive/forth/utilities/order.fs
It's rather too sparsely commented at the moment -- maybe the
earlier messages in this thread can serve as a temporary
substitute for explanation.
The words are:
>ORDER ORDER> ORDER@ ORDER! -ORDER +ORDER
As for what should be proposed as standard, my reading is that
>ORDER has a lot of support, ORDER> maybe less, ORDER@ and
ORDER! somewhat less, -ORDER and +ORDER maybe still less.
I do think a case can be made that if >ORDER were to be
accepted, the meanings of all the others should at least be
reserved on the grounds of logical inevitability, or existing
practice which is not contradictory if not that common.
It has crossed my mind that >O, O>, O@, and O! might be better
names for the first four, with ( O: ... -- ... ) as search-order
stack notation.
The tests are here:
http://www-personal.umich.edu/~williams/archive/forth/utilities/order-test.fs
The part of order-test.fs which defines O{, O->, and }O could be
factored out as a library that extends ttester to include the
order stack. I tried to include sufficient comments.
At present the testing of those three words has not been
physically disentangled from that of the first four order words
above, but I *think* the two sets are independently tested
without circular assumptions. Works with pfe and gforth.
Feedback would be welcomed.
-- David
P.S. If nobody objects, including the direct contributors to
the code below, the "TBA" license will be replaced by "Public
Domain". E.g., Michael Gassanenko, Bill Muench, Bruce
McFarling, gforth, whoever I've overlooked, etc.
----------
( Title: Search-order extension reference library
File: order.fs
Version: 0.5.0
Revised: February 2, 2010
Anthologist: David N. Williams
License: TBA
The date above may reflect cosmetic changes not logged here.
Version 0.5.0
31Jan10 * Started.
02Feb10 * Revised +ORDER to use >ORDER.
The word definitions in this file are consolidated from
contributions to the comp.lang.forth thread:
Newsgroups: comp.lang.forth
From: "David N. Williams" <will...@umich.edu>
Date: Fri, 22 Jan 2010 11:41:50 -0500
Local: Fri, Jan 22 2010 11:41 am
Subject: >ORDER ORDER> ORDER@
http://groups.google.com/group/comp.lang.forth/browse_frm/thread/c26bb6faeaae145a?hl=en#
)
[UNDEFINED] >ORDER [IF]
: >order ( wid -- ) ( order: -- wid ) >r get-order r> swap 1+ set-order ;
[THEN]
: order> ( order: wid -- ) ( -- wid ) get-order swap >r 1- set-order r> ;
\ Internal factor, synonym for DISCARD, DPANS94 A.16.6.2.0715:
: drops ( xn ... x1 n -- ) 0 ?DO drop LOOP ;
: order@ ( order: wid -- wid ) ( -- wid ) get-order over >r drops r> ;
: order! ( wid -- ) ( order: wid' -- wid ) previous >order ;
\ Internal factor:
: _-ORDER ( w wid*n n -- wid*n w n ) ( remove from search order )
dup IF
1- swap >r ( >> ) RECURSE ( << ) ( wid*i w' n (R wid*j )
over r@ xor IF 1+ r> -rot EXIT THEN r> drop
THEN ;
: -order ( wid -- ) get-order _-order nip set-order ;
: +order ( wid -- ) dup -order >order ;
Anton Ertl
>The words are:
>
> >ORDER ORDER> ORDER@ ORDER! -ORDER +ORDER
>
>As for what should be proposed as standard, my reading is that
>>ORDER has a lot of support, ORDER> maybe less, ORDER@ and
>ORDER! somewhat less, -ORDER and +ORDER maybe still less.
>
>I do think a case can be made that if >ORDER were to be
>accepted, the meanings of all the others should at least be
>reserved on the grounds of logical inevitability, or existing
>practice which is not contradictory if not that common.
There is just one problem: The way that CfVs work, implementors can
say whether their implementation supports the complete proposal. And
programmers can say that they use the proposal, but there is normally
no provision for saying which parts they use.
So if you want to propose all of these words, I suggest that you do it
in several RfDs (and later CfVs), so that implementors and programmers
can give more fine-grained feedback about what they implement and use.
E.g., I don't think I will implement a proposal in Gforth that
includes -ORDER and/or +ORDER.
>It has crossed my mind that >O, O>, O@, and O! might be better
>names for the first four, with ( O: ... -- ... ) as search-order
>stack notation.
Cute, but >ORDER has existing practice, and the search order is not so
heavily used to merit such short and somewhat cryptic names.
>P.S. If nobody objects, including the direct contributors to
>the code below, the "TBA" license will be replaced by "Public
>Domain". E.g., Michael Gassanenko, Bill Muench, Bruce
>McFarling, gforth, whoever I've overlooked, etc.
Fine with me. I doubt that I have contributed anything that's
significant for copyright anyway.
Bruce McFarling
wrote:
> E.g., I don't think I will implement a proposal in Gforth that
> includes -ORDER and/or +ORDER.
Going through Niclos-alpha and using those as factors, I used ORDER@
ORDER! and >ORDER, but not -ORDER or +ORDER
Coos Haak
Pardon my asking, but what is this Niclos that some keep referring to?
Bruce McFarling
> Pardon my asking, but what is this Niclos that some keep referring to?
I expect I am the only person who ever refers to it.
Its an experiment with a minimal-implementation
friendly library oversight system that I've
mentioned here on one or two occasions and have
posted an incomplete implementation of.
It was inspired by the mess I made when I tried to
split off pieces of BMW (another vanilla portable
text editor based on Leo Wong's MF) for use in
other applications.
Its a back-burner project, but I guess that puts
it a step ahead of several back of the closet
projects I have. I'm slowly implementing parts
of the specification and/or working out how to
eliminate/simplify parts.
So far it needs CORE BLOCK SEARCH STRING and
:NONAME ?DO and REFILL from CORE EXT.
David N. Williams
> "David N. Williams"<will...@umich.edu> writes:
>> The words are:
>>
>> >ORDER ORDER> ORDER@ ORDER! -ORDER +ORDER
>>
>> As for what should be proposed as standard, my reading is that
>>> ORDER has a lot of support, ORDER> maybe less, ORDER@ and
>> ORDER! somewhat less, -ORDER and +ORDER maybe still less.
>
> There is just one problem: The way that CfVs work, implementors can
> say whether their implementation supports the complete proposal. And
> programmers can say that they use the proposal, but there is normally
> no provision for saying which parts they use.
>
> So if you want to propose all of these words, I suggest that you do it
> in several RfDs (and later CfVs), so that implementors and programmers
> can give more fine-grained feedback about what they implement and use.
Somewhere in there, this would pass my "not worth the effort"
threshhold.
> E.g., I don't think I will implement a proposal in Gforth that
> includes -ORDER and/or +ORDER.
Fair warning, fair enough. :-)
Maybe after a little more discussion, I would hope to guess the
maximum set that has a reasonable chance to pass, and propose
only that in the yet to appear RfD.
One of my concerns is that, if a subset of
>ORDER ORDER> ORDER@ ORDER!
containing >ORDER is sanctioned (possibly consisting only of
>ORDER), the remaining four names are so natural that using them
for other actions would be downright dissonant.
Maybe that problem would be at least weakly addressed by
submitting the implementation of all six words (with tests) as
an ordinary library to FLAG. That would not "officially"
reserve names, but might exert a mild pressure.
Another possibility would be to suspend the RfD for a bit and
just submit the library.
>> It has crossed my mind that>O, O>, O@, and O! might be better
>> names for the first four, with ( O: ... -- ... ) as search-order
>> stack notation.
>
> Cute, but>ORDER has existing practice, and the search order is not so
> heavily used to merit such short and somewhat cryptic names.
Okay. Although there seems to be some feeling that the search
order has untapped potential. :-)
>> P.S. If nobody objects, including the direct contributors to
>> the code below, the "TBA" license will be replaced by "Public
>> Domain". E.g., Michael Gassanenko, Bill Muench, Bruce
>> McFarling, gforth, whoever I've overlooked, etc.
>
> Fine with me. I doubt that I have contributed anything that's
> significant for copyright anyway.
Thanks.
-- David
Anton Ertl
>On 2/14/10 12:15 PM, Anton Ertl wrote:
>> "David N. Williams"<will...@umich.edu> writes:
>>> The words are:
>>>
>>> >ORDER ORDER> ORDER@ ORDER! -ORDER +ORDER
>> So if you want to propose all of these words, I suggest that you do it
>> in several RfDs (and later CfVs), so that implementors and programmers
>> can give more fine-grained feedback about what they implement and use.
>
>Somewhere in there, this would pass my "not worth the effort"
>threshhold.
If you don't want to propose all these words, that may be just as
well.
>One of my concerns is that, if a subset of
>
> >ORDER ORDER> ORDER@ ORDER!
>
>containing >ORDER is sanctioned (possibly consisting only of
>>ORDER), the remaining four names are so natural that using them
>for other actions would be downright dissonant.
>
>Maybe that problem would be at least weakly addressed by
>submitting the implementation of all six words (with tests) as
>an ordinary library to FLAG. That would not "officially"
>reserve names, but might exert a mild pressure.
Yes. Or maybe document them in COMUS (but I don't know how to get
write access there).
Bruce McFarling
> One of my concerns is that, if a subset of
> >ORDER ORDER> ORDER@ ORDER!
> containing >ORDER is sanctioned (possibly consisting only of
> ">ORDER"), the remaining four names are so natural that using
> them for other actions would be downright dissonant.
Surely at least ORDER@ and >ORDER and ORDER!, since that leaves ALSO
as
: ALSO ( O: w0 ... wn -- O: w0 ... wn wn ) ORDER@ >ORDER ;
and Forth-83 VOCABULARY as:
: VOCABULARY83 WORDLIST CREATE , DOES> @ ORDER! ;
with I guess the previous VOCABULARY as:
: VOCABULARY79 WORDLIST CREATE , DOES> @ >ORDER ;
Push, pop, replace top and copy top are a natural set of operations
for a stack. In a proposal, +ORDER and -ORDER ought to be an extension
if included at all.
David N. Williams
> On Feb 15, 5:14 pm, "David N. Williams"<willi...@umich.edu> wrote:
>> One of my concerns is that, if a subset of
>
>> >ORDER ORDER> ORDER@ ORDER!
>
>> containing>ORDER is sanctioned (possibly consisting only of
>> ">ORDER"), the remaining four names are so natural that using
Not the wording I intended! :-(
Should be "those remaining of the four names".
>> them for other actions would be downright dissonant.
>
> Surely at least ORDER@ and>ORDER and ORDER!, since that leaves ALSO
> as
>
> : ALSO ( O: w0 ... wn -- O: w0 ... wn wn ) ORDER@ >ORDER ;
>
> and Forth-83 VOCABULARY as:
>
> : VOCABULARY83 WORDLIST CREATE , DOES> @ ORDER! ;
>
> with I guess the previous VOCABULARY as:
>
> : VOCABULARY79 WORDLIST CREATE , DOES> @ >ORDER ;
Thanks for pointing these out.
> Push, pop, replace top and copy top are a natural set of operations
> for a stack.
My feeling, too.
> In a proposal, +ORDER and -ORDER ought to be an extension
> if included at all.
I was thinking of everything as an extension, for the extension
section of the already optional Search-Order word set. But my
inclination now is to include neither +ORDER nor -ORDER.
I wonder how much opposition there would be to including all of
the other four, let's say, among those who do not object to
">ORDER"?
-- David
Anton Ertl
> > : VOCABULARY79 WORDLIST CREATE , DOES> @ >ORDER ;
Forth-79 only has a CONTEXT vocabulary (that chained to FORTH), no
search-order stack. So the definition should be:
: VOCABULARY79 WORDLIST CREATE , DOES> @ CONTEXT ! ;
(or replace CONTEXT ! with ORDER! if you want).
>I was thinking of everything as an extension, for the extension
>section of the already optional Search-Order word set.
Yes, but CfVs and extension queries treat all words of a proposal as
one unit.
>I wonder how much opposition there would be to including all of
>the other four, let's say, among those who do not object to
>">ORDER"?
I think that CONTEXT has more common practice than ORDER@ ORDER!
(e.g., it's implemented in Gforth, bigForth and apparently VFX, and
it's also in earlier standards), so if you want to propose one of
these words, IMO CONTEXT is the best choice. In theory ORDER@ and
ORDER! allow more implementation freedoms, but I don't think any
implementation makes use of that in practice or ever will.
That being said, I only find >ORDER useful, but I could live with the
others and would implement (but not use) them if proposed.
Bruce McFarling
wrote:
> I think that CONTEXT has more common practice than ORDER@ ORDER!
> (e.g., it's implemented in Gforth, bigForth and apparently VFX, and
> it's also in earlier standards), so if you want to propose one of
> these words, IMO CONTEXT is the best choice.
But in some earlier Forths, changing context changed not just the
first vocabulary in the search order but the entire search order.
And of course, ORDER@ and ORDER! can always be supported whether or
not the system has a CONTEXT variable, its just that ORDER@ and ORDER!
are more efficient if you know the implementation details. If there is
a "stack under CONTEXT" implementation, the GET-ORDER and SET-ORDER
operations and discarding of the rest of the stack is replaced by:
: ORDER@ ( -- wid0 ) CONTEXT @ ;
: ORDER! ( wid0 -- ) CONTEXT ! ;
... and if there is a pure stack implementation, ORDER@ and ORDER! are
likely built with existing stack access factors.
The search order does not require that a CONTEXT variable exists, and
of course if it does, it is allowed to be a double variable or a
character wide variable, depending on the implementation. Since wid's
have to be cells on the stack, they'd have factors that can do the
translation if needed:
: ORDER@ ( -- wid0 ) VOCABS 1+ C@ ;
: ORDER@ ( -- wid0 ) CONTEXT 2@ >WID ;
David N. Williams
time, medical issues have intervened, and I expect it to be
delayed for possibly two or more weeks. The medical prognosis
is very good, but requires some attention.
What I had finished was an experimental library, with tests:
http://www-personal.umich.edu/~williams/archive/forth/utilities/#order
The four files there were actually posted in mid-February, with
the intent of submitting them to FLAG, once the licensing issue
is resolved for order.fs. For that, I still need to hear from
Michael Gassanenko and Bill Muench whether public domain or
other open source is okay with them -- I've been too distracted
even to try to email them.
The library contains all six words:
>ORDER ORDER> ORDER@ ORDER!
-ORDER +ORDER
I plan to propose only the first four in the RfD, and if there's
too much objection would fall back to the subset most likely to
pass, with >ORDER by itself the ultimate fallback.
Among the four files at the link above is an extension of
ttester to the search order stack, called otester.fs, which
takes a somewhat more aggressive approach to preserving the
initial order stack than does ttester for the data and
floating-point stacks. Maybe it's overkill.
-- David