16.6.2.0715 ALSO

( -- )
Transform the search order consisting of widn, ... wid2, wid1 (where
wid1 is searched first) into widn, ... wid2, wid1, wid1. An ambiguous
condition exists if there are too many word lists in the search order.
--------------------------------------------------

Why is wid1 duplicated? I'm not sure what this means - what is the
purpose behind this?

(I do realise the spec isn't the right place for a wordlists 101,
hence the question here).

Thanks

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>( -- )
>Transform the search order consisting of widn, ... wid2, wid1 (where
>wid1 is searched first) into widn, ... wid2, wid1, wid1. An ambiguous
>condition exists if there are too many word lists in the search order.
>--------------------------------------------------
>
>Why is wid1 duplicated?

So that the next invocation of a vocabulary can replace it.

E.g., after ALSO FORTH you then have

widn, ..., wid2, wid1, FORTH

> I'm not sure what this means - what is the
>purpose behind this?

ALSO is a DUP on the search order stack.

Vocabularies and ALSO are ususual in their handling. Better don't
think too much about it.

- 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 2012: http://www.euroforth.org/ef12/

On Jul 31, 3:43*pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
> >( -- )
> >Transform the search order consisting of widn, ... wid2, wid1 (where
> >wid1 is searched first) into widn, ... wid2, wid1, wid1. An ambiguous
> >condition exists if there are too many word lists in the search order.
> >--------------------------------------------------
>
> >Why is wid1 duplicated?
>
> So that the next invocation of a vocabulary can replace it.
>
> E.g., after ALSO FORTH you then have
>
> widn, ..., wid2, wid1, FORTH
>
> > I'm not sure what this means - what is the
> >purpose behind this?
>
> ALSO is a DUP on the search order stack.
>
> Vocabularies and ALSO are ususual in their handling. *Better don't
> think too much about it.
>
> - 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 2012:http://www.euroforth.org/ef12/

Okay. So naming a vocab does not append it to the search order. It
over-writes the last one?

That's a bit strange.

On 7/31/12 11:08 AM, Mark Wills wrote:
> On Jul 31, 3:43 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> [...]
>>
>> ALSO is a DUP on the search order stack.
>>
>> Vocabularies and ALSO are ususual in their handling. Better don't
>> think too much about it.
>> [...]
>
> Okay. So naming a vocab does not append it to the search order. It
> over-writes the last one?
>
> That's a bit strange.

The traditional, nonstandard VOCABULARY word creates named
vocabularies which replace the top item on the search-order
stack (ostack) when invoked. So after

VOCABULARY B

you would do

ALSO B

to add the B wid to the top of the ostack.

I personally don't like that behavior, although Krishna and I
used it in our modules library, so named modules would behave
like the standard word FORTH.

-- David

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> ( -- )
> Transform the search order consisting of widn, ... wid2, wid1 (where
> wid1 is searched first) into widn, ... wid2, wid1, wid1. An ambiguous
> condition exists if there are too many word lists in the search order.
> --------------------------------------------------
>
> Why is wid1 duplicated? I'm not sure what this means - what is the
> purpose behind this?

Because it's used in this form:

ALSO FORTH

Note that FORTH overwrites the top item on the search order stack.
ALSO is just DUP for the search order stack.

Andrew.

I'm looking for alternatives to ANS wordlists and search order.
It's costly to implement and confusing in use. There has to be
a better way.

LMI disliked ONLY ALSO and appeared to get by with a scheme
that involved searching just CONTEXT CURRENT FORTH.
As they implemented cross-compilers with it, it can't have been
too bad!

Can anyone point me to other forths with simple but effective
search schemes?

On Aug 8, 7:28*am, "Ed" <inva...@nospam.com> wrote:
> I'm looking for alternatives to ANS wordlists and search order.
> It's costly to implement and confusing in use. *There has to be
> a better way.
>
> LMI disliked ONLY ALSO and appeared to get by with a scheme
> that involved searching just *CONTEXT CURRENT FORTH.
> As they implemented cross-compilers with it, it can't have been
> too bad!
>
> Can anyone point me to other forths with simple but effective
> search schemes?

Personally I would be up for a completely new paradigm with regards to
wordlists. The current system is cryptic, and, well, awful quite
frankly!

Maybe I'll sketch a few ideas down on paper. Too late now to write a
paper for EuroForth...

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>Maybe I'll sketch a few ideas down on paper. Too late now to write a
>paper for EuroForth...

Only if you want to submit a refereed paper. For non-refereed papers
(industrial stream) the deadline is September 5, so you have 4 weeks,
which should be enough.

- 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 2012: http://www.euroforth.org/ef12/

On Aug 8, 9:22*am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> On Aug 8, 7:28*am, "Ed" <inva...@nospam.com> wrote:
>
> > I'm looking for alternatives to ANS wordlists and search order.
> > It's costly to implement and confusing in use. *There has to be
> > a better way.
>
> > LMI disliked ONLY ALSO and appeared to get by with a scheme
> > that involved searching just *CONTEXT CURRENT FORTH.
> > As they implemented cross-compilers with it, it can't have been
> > too bad!
>
> > Can anyone point me to other forths with simple but effective
> > search schemes?
>
> Personally I would be up for a completely new paradigm with regards to
> wordlists. The current system is cryptic, and, well, awful quite
> frankly!
>
> Maybe I'll sketch a few ideas down on paper. Too late now to write a
> paper for EuroForth...

The simplicity of ALSO and friends can be seen in the implementation;
it's not complex at all. Untested.

( assumes existence of a ROOT vocabulary )
\ vocabulary root

n ( pick your n ) cells allot here 0 , constant context-
base
variable context context-base context ! ( stack )
variable current

: definitions ( -- ) context @ @ current ! ;
: previous ( -- ) cell context +! ;
: also ( -- ) context @ dup @ swap cell- dup ! ! ;
: only ( -- ) context-base context ! also root also ;
: vocabulary ( -- <name> ) create wordlist , does> context @ ! ;

vocabulary forth

only forth definitions

Alex McDonald wrote:
> ...
> The simplicity of ALSO and friends can be seen in the implementation;
> it's not complex at all. Untested.
>
> ( assumes existence of a ROOT vocabulary )
> \ vocabulary root
>
> n ( pick your n ) cells allot here 0 , constant context-
> base
> variable context context-base context ! ( stack )
> variable current
>
> : definitions ( -- ) context @ @ current ! ;
> : previous ( -- ) cell context +! ;
> : also ( -- ) context @ dup @ swap cell- dup ! ! ;
> : only ( -- ) context-base context ! also root also ;
> : vocabulary ( -- <name> ) create wordlist , does> context @ ! ;
>
> vocabulary forth
>
> only forth definitions

I want to know whether these things are necessary. The underlying
premise of ANS' ONLY ALSO and associated tools is that Forth
*requires* complicated search orders to get a job done. Does it?
Apparently LMI didn't feel it did.

I don't have the background to give a definitive answer. If it boils
down to a choice between ANS compliance and simplicity then
I want to know.

"Ed" <invalid@nospam.com> writes:
>I want to know whether these things are necessary. The underlying
>premise of ANS' ONLY ALSO and associated tools is that Forth
>*requires* complicated search orders to get a job done. Does it?

My impression is that in most cases we don't need to use several
wordlists; we can just choose lots of non-conflicting names (the
hyphen-haters hate that).

OTOH, when you need several wordlists, the search order stack is a
good concept; however, I prefer dealing with Wids and using >ORDER to
having named vocabularies and ALSO. The fig-Forth approach was
definitely lacking.

>I don't have the background to give a definitive answer. If it boils
>down to a choice between ANS compliance and simplicity then
>I want to know.

The search order word set is not a required word set.

- 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 2012: http://www.euroforth.org/ef12/

On Sat, 11 Aug 2012, Ed wrote:

> Date: Sat, 11 Aug 2012 22:13:24 +1000
> From: Ed <invalid@nospam.com>
> Newsgroups: comp.lang.forth
> Subject: Re: ALSO - anything better?
>
> Alex McDonald wrote:
>> ...
>> The simplicity of ALSO and friends can be seen in the implementation;
>> it's not complex at all. Untested.
>>
>> ( assumes existence of a ROOT vocabulary )
>> \ vocabulary root
>>
>> n ( pick your n ) cells allot here 0 , constant context-
>> base
>> variable context context-base context ! ( stack )
>> variable current
>>
>> : definitions ( -- ) context @ @ current ! ;
>> : previous ( -- ) cell context +! ;
>> : also ( -- ) context @ dup @ swap cell- dup ! ! ;
>> : only ( -- ) context-base context ! also root also ;
>> : vocabulary ( -- <name> ) create wordlist , does> context @ ! ;
>>
>> vocabulary forth
>>
>> only forth definitions
>
> I want to know whether these things are necessary. The underlying
> premise of ANS' ONLY ALSO and associated tools is that Forth
> *requires* complicated search orders to get a job done. Does it?
> Apparently LMI didn't feel it did.
>
> I don't have the background to give a definitive answer. If it boils
> down to a choice between ANS compliance and simplicity then
> I want to know.



I have long believed that the Forth search order/vocabulary system is
inferior to a proper namespace. The major problem addressed by namespaces
is the ability to unambiguously specify a word name by fully qualifying
it, rather than relying upon the order of vocabularies on some nebulous
stack.

This may sound heretic, but Forth isn't dead (yet), and it could stand
some improvements, and simple modifications, particularly those which
don't change the character of the language, nor hurt its strengths.

The namespace facility within Tcl is a decent approach which could easily
be adopted by the Forth language in a natural manner. IMHO.

Cheers,
Rob Sciuk

Spam@ControlQ.com writes:
>The namespace facility within Tcl is a decent approach which could easily
>be adopted by the Forth language in a natural manner. IMHO.

For those of us who don't know TCL, maybe you could explain how such
an adoption might look like, and what the advantages would be.

- 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 2012: http://www.euroforth.org/ef12/

Spam@controlq.com wrote:
> On Sat, 11 Aug 2012, Ed wrote:
>
>> Date: Sat, 11 Aug 2012 22:13:24 +1000
>> From: Ed <invalid@nospam.com>
>> Newsgroups: comp.lang.forth
>> Subject: Re: ALSO - anything better?
>>
>> Alex McDonald wrote:
>>> ...
>>> The simplicity of ALSO and friends can be seen in the implementation;
>>> it's not complex at all. Untested.
>>>
>>> ( assumes existence of a ROOT vocabulary )
>>> \ vocabulary root
>>>
>>> n ( pick your n ) cells allot here 0 , constant context-
>>> base
>>> variable context context-base context ! ( stack )
>>> variable current
>>>
>>> : definitions ( -- ) context @ @ current ! ;
>>> : previous ( -- ) cell context +! ;
>>> : also ( -- ) context @ dup @ swap cell- dup ! ! ;
>>> : only ( -- ) context-base context ! also root also ;
>>> : vocabulary ( -- <name> ) create wordlist , does> context @ ! ;
>>>
>>> vocabulary forth
>>>
>>> only forth definitions
>>
>> I want to know whether these things are necessary. The underlying
>> premise of ANS' ONLY ALSO and associated tools is that Forth
>> *requires* complicated search orders to get a job done. Does it?
>> Apparently LMI didn't feel it did.
>>
>> I don't have the background to give a definitive answer. If it boils
>> down to a choice between ANS compliance and simplicity then
>> I want to know.
>
> I have long believed that the Forth search order/vocabulary system
> is inferior to a proper namespace. The major problem addressed by
> namespaces is the ability to unambiguously specify a word name by
> fully qualifying it, rather than relying upon the order of
> vocabularies on some nebulous stack.

What do you mean? It's perfectly normal to say "using namespace blah"
in non-Forth languages, and that's what wordlists do. I can't see any
difference. If it's really important to you to specify exactly Word X
from Wordlist Y, you can do that too. What's missing?

Andrew.

On 8/11/12 2:13 AM, Ed wrote:
> Alex McDonald wrote:
>> ...
>> The simplicity of ALSO and friends can be seen in the implementation;
>> it's not complex at all. Untested.
>>
>> ( assumes existence of a ROOT vocabulary )
>> \ vocabulary root
>>
>> n ( pick your n ) cells allot here 0 , constant context-
>> base
>> variable context context-base context ! ( stack )
>> variable current
>>
>> : definitions ( -- ) context @ @ current ! ;
>> : previous ( -- ) cell context +! ;
>> : also ( -- ) context @ dup @ swap cell- dup ! ! ;
>> : only ( -- ) context-base context ! also root also ;
>> : vocabulary ( -- <name> ) create wordlist , does> context @ ! ;
>>
>> vocabulary forth
>>
>> only forth definitions
>
> I want to know whether these things are necessary. The underlying
> premise of ANS' ONLY ALSO and associated tools is that Forth
> *requires* complicated search orders to get a job done. Does it?
> Apparently LMI didn't feel it did.
>
> I don't have the background to give a definitive answer. If it boils
> down to a choice between ANS compliance and simplicity then
> I want to know.

No, of course they aren't necessary. This is an optional wordset.
Historically, Forthers have found wordlists useful for namespace
management and the secondary benefit of shortening searches and hence
speeding up compiles, but if that isn't important to you, don't use it.

There have been several approaches to namespace management over the
years, starting in 1971 when Chuck's systems at NRAO needed to
distinguish I (loop counter) from I (register name in assembler) from I
(insert command in editor) and related conflicts. Bill Ragsdale
introduced the ONLY/ALSO scheme in the early 80's. FORTH, Inc. used a
simpler scheme that supported up to 8 wordlists, until the adoption of
Forth94 when the TC adopted a much improved ONLY/ALSO scheme.

Programmers' styles in this regard differ a lot. FORTH, Inc. was
perfectly happy with 8 wordlists, and rarely used more than 4 except in
cross- or meta-compilers, but the Forth94 TC heard from people who used
"hundreds", and since Forth94 they have become popular mechanisms for
implementing OOPs. And in SwiftForth, with over 3,000 words as booted,
they are very helpful.

Nobody is going to force you to use them, though.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================