Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #14570 > unrolled thread

16.6.2.0715 ALSO

Back to article view | Back to comp.lang.forth

Contents

  16.6.2.0715 ALSO Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-31 05:33 -0700
    Re: 16.6.2.0715 ALSO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-31 14:43 +0000
      Re: 16.6.2.0715 ALSO Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-31 08:08 -0700
        Re: 16.6.2.0715 ALSO "David N. Williams" <williams@umich.edu> - 2012-07-31 11:35 -0400
    Re: 16.6.2.0715 ALSO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-31 11:03 -0500
    ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-08 16:28 +1000
      Re: ALSO - anything better? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-08 01:22 -0700
        Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-08 10:33 +0000
        Re: ALSO - anything better? Alex McDonald <blog@rivadpm.com> - 2012-08-08 03:52 -0700
          Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-11 22:13 +1000
            Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-11 12:15 +0000
              Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-13 21:22 +1000
                Re: ALSO - anything better? Alex McDonald <blog@rivadpm.com> - 2012-08-13 04:44 -0700
                  Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-14 18:46 +1000
                Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-13 10:03 -0500
            Re: ALSO - anything better? Spam@ControlQ.com - 2012-08-11 11:31 -0400
              Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-11 16:01 +0000
                Re: ALSO - anything better? Spam@ControlQ.com - 2012-08-12 16:02 -0400
              Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-11 11:37 -0500
            Re: ALSO - anything better? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-11 08:04 -1000
              Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-12 13:26 +1000
                Re: ALSO - anything better? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-11 21:55 -1000
                  Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-14 17:18 +1000
                    Re: ALSO - anything better? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-13 21:53 -1000
                      Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-14 19:25 +1000
                        Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-14 19:40 +1000
                    Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-15 12:57 +0000
                      Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-15 10:09 -0500
                        Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-15 15:12 +0000
                          Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-15 10:21 -0500
                            Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-15 16:26 +0000
                              Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-15 12:08 -0500
                                Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-15 17:38 +0000
                                  Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-15 13:10 -0500
                            Re: ALSO - anything better? mhx@iae.nl - 2012-08-15 13:49 -0700
                              Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-16 12:34 +0000
                                Re: ALSO - anything better? mhx@iae.nl (Marcel Hendrix) - 2012-08-16 20:13 +0200
                                  Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-17 14:07 +0000
                      Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-16 14:08 +1000
                        Re: ALSO - anything better? Alex McDonald <blog@rivadpm.com> - 2012-08-16 02:30 -0700
                          Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-16 11:51 +0000
                          Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-18 03:09 +1000
                            Re: ALSO - anything better? Alex McDonald <blog@rivadpm.com> - 2012-08-17 17:13 -0700
                              Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-19 14:13 +1000
                                Re: ALSO - anything better? Alex McDonald <blog@rivadpm.com> - 2012-08-19 09:57 -0700
                        Re: ALSO - anything better? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-08-16 10:28 +0000
                          Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-16 12:38 +0000
                            Re: ALSO - anything better? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-16 11:07 -0500
                          Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-17 22:12 +1000
                        Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-16 12:45 +0000
                          Re: ALSO - anything better? "Ed" <invalid@nospam.com> - 2012-08-18 03:14 +1000
                            Re: ALSO - anything better? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-17 17:31 +0000
                            Re: ALSO - anything better? Alex McDonald <blog@rivadpm.com> - 2012-08-17 17:14 -0700
                          Re: ALSO - anything better? BruceMcF <agila61@netscape.net> - 2012-08-18 10:16 -0700
                            Re: ALSO - anything better? "David N. Williams" <williams@umich.edu> - 2012-08-18 15:41 -0400
                Re: ALSO - anything better? BruceMcF <agila61@netscape.net> - 2012-08-15 12:14 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14937 — Re: ALSO - anything better?

Elizabeth D. Rather wrote:
> On 8/11/12 2:13 AM, Ed wrote:
> > ...
> > 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.

I use search orders.  The question is how complex do they practically
need to be.

> 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.

So from your experience lengthy search orders are not necessary (?)
That's not too different a position from LMI which managed with three.

Interesting!

[toc] | [prev] | [next] | [standalone]

#14940 — Re: ALSO - anything better?

On 8/11/12 5:26 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 8/11/12 2:13 AM, Ed wrote:
>>> ...
>>> 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.
>
> I use search orders.  The question is how complex do they practically
> need to be.

It really depends on how you're using them, and what level of 
portability you want to support.

>> 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.
>
> So from your experience lengthy search orders are not necessary (?)
> That's not too different a position from LMI which managed with three.
>
> Interesting!

Many search orders are necessary if you're using them in an OOP 
implementation. Eight are necessary for a cross-compiler. Beyond that, 
it's really up to you and your programming style.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#14954 — Re: ALSO - anything better?

Elizabeth D. Rather wrote:
> ...
> Many search orders are necessary if you're using them in an OOP
> implementation. Eight are necessary for a cross-compiler. Beyond that,
> it's really up to you and your programming style.

Apparently LMI cross-compiled with *three* (context current forth).
The commercial Nautilus cross-compiler was, I believe, fig-Forth
which had a similar limited search order.

Whether one searches by stacking vocabs, or explicitly executing
them as required, the result should be the same.  No?

Stacking vocabs has the same issue as too many items on the
data stack - it's difficult to keep track.  And then there's the
support words to save/restore search order etc.

If the only drawback of LMI's method is that it requires extra
typing, it may be a small price to pay.  Implementation is simpler
than ANS and saving/restoring search can be as easy as
CONTEXT 2@  ... CONTEXT 2!

[toc] | [prev] | [next] | [standalone]

#14955 — Re: ALSO - anything better?

On 8/13/12 9:18 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> ...
>> Many search orders are necessary if you're using them in an OOP
>> implementation. Eight are necessary for a cross-compiler. Beyond that,
>> it's really up to you and your programming style.
>
> Apparently LMI cross-compiled with *three* (context current forth).
> The commercial Nautilus cross-compiler was, I believe, fig-Forth
> which had a similar limited search order.

CONTEXT and CURRENT aren't search orders, they're roles. The traditional 
basic search orders are FORTH, ASSEMBLER, and EDITOR. Any of these may 
be CONTEXT (primary search order) or CURRENT (compiling search order) at 
any time.

Cross & meta compilers at FORTH, Inc. add:

HOST -- the host system's FORTH plus some added target compiling words;
COMPILER -- words executed inside target colon definitions, equivalent
    to IMMEDIATE words in a resident system;
INTERPRETER -- words executed on the host to build target definitions,
    such as : CREATE CONSTANT etc.
TARGET -- words to be executed only on the target system.
(ASSEMBLER) -- the target system's assembler.

It's actually a little more complicated than that, but not much.

> Whether one searches by stacking vocabs, or explicitly executing
> them as required, the result should be the same.  No?
>
> Stacking vocabs has the same issue as too many items on the
> data stack - it's difficult to keep track.  And then there's the
> support words to save/restore search order etc.

In practice, it isn't that difficult.

> If the only drawback of LMI's method is that it requires extra
> typing, it may be a small price to pay.  Implementation is simpler
> than ANS and saving/restoring search can be as easy as
> CONTEXT 2@  ... CONTEXT 2!

Well, a lot of people found it inadequate. I haven't looked at it, but 
Ray Duncan was around when this part of Forth94 was defined, and he 
didn't have any trouble with it as I recall.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#14957 — Re: ALSO - anything better?

Elizabeth D. Rather wrote:
> On 8/13/12 9:18 PM, Ed wrote:
> > Elizabeth D. Rather wrote:
> >> ...
> >> Many search orders are necessary if you're using them in an OOP
> >> implementation. Eight are necessary for a cross-compiler. Beyond that,
> >> it's really up to you and your programming style.
> >
> > Apparently LMI cross-compiled with *three* (context current forth).
> > The commercial Nautilus cross-compiler was, I believe, fig-Forth
> > which had a similar limited search order.
>
> CONTEXT and CURRENT aren't search orders, they're roles.
> ...

These are wordlists and the order in which I listed them is what LMI
searches.  I can't remember if Fig searched CURRENT as it used
chained wordlists - but the search always ended with FORTH.

> Cross & meta compilers at FORTH, Inc. add:
>
> HOST -- the host system's FORTH plus some added target compiling words;
> COMPILER -- words executed inside target colon definitions, equivalent
>     to IMMEDIATE words in a resident system;
> INTERPRETER -- words executed on the host to build target definitions,
>     such as : CREATE CONSTANT etc.
> TARGET -- words to be executed only on the target system.
> (ASSEMBLER) -- the target system's assembler.
>
> It's actually a little more complicated than that, but not much.

Surely these are just wordlists?  What's under consideration is the
mechanism by which they're searched.

> > Whether one searches by stacking vocabs, or explicitly executing
> > them as required, the result should be the same.  No?
> >
> > Stacking vocabs has the same issue as too many items on the
> > data stack - it's difficult to keep track.  And then there's the
> > support words to save/restore search order etc.
>
> In practice, it isn't that difficult.

I prefer something easier particularly if it can be implemented cheaper.

> > If the only drawback of LMI's method is that it requires extra
> > typing, it may be a small price to pay.  Implementation is simpler
> > than ANS and saving/restoring search can be as easy as
> > CONTEXT 2@  ... CONTEXT 2!
>
> Well, a lot of people found it inadequate. I haven't looked at it, but
> Ray Duncan was around when this part of Forth94 was defined, and he
> didn't have any trouble with it as I recall.

The ANS Rationale section mentions a member or vendor who
stated they would refuse to implement ANS-Forth if ONLY ALSO
were mandated.  I assumed that person to be Ray.

[toc] | [prev] | [next] | [standalone]

#14958 — Re: ALSO - anything better?

Ed wrote:
> Elizabeth D. Rather wrote:
> > On 8/13/12 9:18 PM, Ed wrote:
> > > Elizabeth D. Rather wrote:
> > >> ...
> > >> Many search orders are necessary if you're using them in an OOP
> > >> implementation. Eight are necessary for a cross-compiler. Beyond that,
> > >> it's really up to you and your programming style.
> > >
> > > Apparently LMI cross-compiled with *three* (context current forth).
> > > The commercial Nautilus cross-compiler was, I believe, fig-Forth
> > > which had a similar limited search order.
> >
> > CONTEXT and CURRENT aren't search orders, they're roles.
> > ...
>
> These are wordlists and the order in which I listed them is what LMI
> searches.  I can't remember if Fig searched CURRENT as it used
> chained wordlists - but the search always ended with FORTH.

Before anyone gets picky that was meant to say:

    "These *represent* wordlists and the order in which I listed them
    is what LMI searches ... "

[toc] | [prev] | [next] | [standalone]

#14965 — Re: ALSO - anything better?

"Ed" <invalid@nospam.com> writes:
>Apparently LMI cross-compiled with *three* (context current forth).
>The commercial Nautilus cross-compiler was, I believe, fig-Forth
>which had a similar limited search order.
>
>Whether one searches by stacking vocabs, or explicitly executing
>them as required, the result should be the same.  No?

No.  See below.

>Stacking vocabs has the same issue as too many items on the
>data stack - it's difficult to keep track.

And yet we use a stack, and not two registers plus a constant (which
would be the equivalent of "context current forth").

And while the number of stack items manipulated within a word should
be three or less, there can be many more items on the stack during
execution that belong to parent or child words and that you don't have
to think about when programming one word.

Likewise, on the search order stack there is usually only one or two
items that I care about, and it's trivial to keep track of that; I
have never felt a need for search order equivalents of SWAP and OVER
(and there are no words for that), another reason why keeping track of
the search order stack is a non-problem.

>  And then there's the
>support words to save/restore search order etc.

Likewise, I have never felt the need to save and restore the search
order.  That's the advantage of the stack design: I just push the
wordlist I want searched on the stack, and when I am done with that, I
remove it with PREVIOUS.  No need for saving and restoring the search
order.

The only case where you need to remove the rest of the search order
(and therefore save and restore the old search order) is if you are
using names that are not in any wordlist that you know is guaranteed
to be on the stack, and you want a guarantee that this name is not
found.  I have not encountered such a need, and the only possible
occasion currently coming to mind is when a system is turnkeyed (and
then you don't want to save and restore the old search order).

- 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/

[toc] | [prev] | [next] | [standalone]

#14966 — Re: ALSO - anything better?

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> The only case where you need to remove the rest of the search order
> (and therefore save and restore the old search order) is if you are
> using names that are not in any wordlist that you know is guaranteed
> to be on the stack, and you want a guarantee that this name is not
> found.

Or you want a particular word in a particular wordlist, and you don't
want any other: the Forth equivalent of java.lang.Object rather than
just plain Object.  It's not quite the same thing.

Andrew.

[toc] | [prev] | [next] | [standalone]

#14967 — Re: ALSO - anything better?

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 
>> The only case where you need to remove the rest of the search order
>> (and therefore save and restore the old search order) is if you are
>> using names that are not in any wordlist that you know is guaranteed
>> to be on the stack, and you want a guarantee that this name is not
>> found.
>
>Or you want a particular word in a particular wordlist, and you don't
>want any other

Then I push that wordlist on top of the search order, no need to
remove the rest of the search order.  Example: The implementation of
EXECUTE-PARSING in Forth-94.

- 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/

[toc] | [prev] | [next] | [standalone]

#14968 — Re: ALSO - anything better?

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> 
>>> The only case where you need to remove the rest of the search order
>>> (and therefore save and restore the old search order) is if you are
>>> using names that are not in any wordlist that you know is guaranteed
>>> to be on the stack, and you want a guarantee that this name is not
>>> found.
>>
>>Or you want a particular word in a particular wordlist, and you don't
>>want any other
> 
> Then I push that wordlist on top of the search order, no need to
> remove the rest of the search order.

How can that possibly work?  You want to make sure that, if the word
is absent, the lookup will fail -- just like the Java example.

Andrew.

[toc] | [prev] | [next] | [standalone]

#14970 — Re: ALSO - anything better?

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> 
>>>> The only case where you need to remove the rest of the search order
>>>> (and therefore save and restore the old search order) is if you are
>>>> using names that are not in any wordlist that you know is guaranteed
>>>> to be on the stack, and you want a guarantee that this name is not
>>>> found.
>>>
>>>Or you want a particular word in a particular wordlist, and you don't
>>>want any other
>> 
>> Then I push that wordlist on top of the search order, no need to
>> remove the rest of the search order.
>
>How can that possibly work?  You want to make sure that, if the word
>is absent, the lookup will fail

You did not write that earlier.  If I want to do that, then yes, I
need to remove the rest.  But that's what I already wrote earlier
(still cited above).  Your "Or" made it appear that you were thinking
of another case that does not have this property.

- 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/

[toc] | [prev] | [next] | [standalone]

#14971 — Re: ALSO - anything better?

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> 
>>>>> The only case where you need to remove the rest of the search order
>>>>> (and therefore save and restore the old search order) is if you are
>>>>> using names that are not in any wordlist that you know is guaranteed
>>>>> to be on the stack, and you want a guarantee that this name is not
>>>>> found.
>>>>
>>>>Or you want a particular word in a particular wordlist, and you don't
>>>>want any other
>>> 
>>> Then I push that wordlist on top of the search order, no need to
>>> remove the rest of the search order.
>>
>>How can that possibly work?  You want to make sure that, if the word
>>is absent, the lookup will fail
> 
> You did not write that earlier. 

Yes I did, but you perhaps failed to see its significance:

> the Forth equivalent of java.lang.Object rather than just plain
> Object.

java.lang.Object is a fully-qualified name.

> If I want to do that, then yes, I need to remove the rest.  But
> that's what I already wrote earlier (still cited above).

Not at all.  You said:

>>>>> The only case where you need to remove the rest of the search
>>>>> order (and therefore save and restore the old search order) is
>>>>> if you are using names that are not in any wordlist that you
>>>>> know is guaranteed to be on the stack, and you want a guarantee
>>>>> that this name is not found.

This is not the case here: you are using names that may (or may not)
be in any wordlist that you know is guaranteed to be on the stack.
That's the point; you don't know, so you have to trim.

Andrew.

[toc] | [prev] | [next] | [standalone]

#14972 — Re: ALSO - anything better?

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> 
>>>>>> The only case where you need to remove the rest of the search order
>>>>>> (and therefore save and restore the old search order) is if you are
>>>>>> using names that are not in any wordlist that you know is guaranteed
>>>>>> to be on the stack, and you want a guarantee that this name is not
>>>>>> found.
>>>>>
>>>>>Or you want a particular word in a particular wordlist, and you don't
>>>>>want any other
>>>> 
>>>> Then I push that wordlist on top of the search order, no need to
>>>> remove the rest of the search order.
>>>
>>>How can that possibly work?  You want to make sure that, if the word
>>>is absent, the lookup will fail
>> 
>> You did not write that earlier. 
>
>Yes I did, but you perhaps failed to see its significance:
>
>> the Forth equivalent of java.lang.Object rather than just plain
>> Object.
>
>java.lang.Object is a fully-qualified name.

And it's a name that is present, no?  So no, you did not write
anything about absent names, not even in an implied way.

>> If I want to do that, then yes, I need to remove the rest.  But
>> that's what I already wrote earlier (still cited above).
>
>Not at all.  You said:
>
>>>>>> The only case where you need to remove the rest of the search
>>>>>> order (and therefore save and restore the old search order) is
>>>>>> if you are using names that are not in any wordlist that you
>>>>>> know is guaranteed to be on the stack, and you want a guarantee
>>>>>> that this name is not found.
>
>This is not the case here: you are using names that may (or may not)
>be in any wordlist that you know is guaranteed to be on the stack.
>That's the point; you don't know, so you have to trim.

Sorry, I totally fail to see what points you are trying to make.  It's
unclear what you mean with basically everything in the last paragraph.
I could imagine a variety of interpretations of it that maybe make it
consistent with what you write before, but discussing any one of them
is pretty pointless, because it's probably not what you had in mind,
and there are too many to sensibly discuss them all.

In any case, maybe you failed to understand the significance of "and
you want a guarantee that this name is not found.".

- 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/

[toc] | [prev] | [next] | [standalone]

#14973 — Re: ALSO - anything better?

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>> 
>>>>>>> The only case where you need to remove the rest of the search order
>>>>>>> (and therefore save and restore the old search order) is if you are
>>>>>>> using names that are not in any wordlist that you know is guaranteed
>>>>>>> to be on the stack, and you want a guarantee that this name is not
>>>>>>> found.
>>>>>>
>>>>>>Or you want a particular word in a particular wordlist, and you don't
>>>>>>want any other
>>>>> 
>>>>> Then I push that wordlist on top of the search order, no need to
>>>>> remove the rest of the search order.
>>>>
>>>>How can that possibly work?  You want to make sure that, if the word
>>>>is absent, the lookup will fail
>>> 
>>> You did not write that earlier. 
>>
>>Yes I did, but you perhaps failed to see its significance:
>>
>>> the Forth equivalent of java.lang.Object rather than just plain
>>> Object.
>>
>>java.lang.Object is a fully-qualified name.
> 
> And it's a name that is present, no?

It's an example.  It could have been foo.bar.Baz.

> So no, you did not write anything about absent names, not even in an
> implied way.
> 
>>> If I want to do that, then yes, I need to remove the rest.  But
>>> that's what I already wrote earlier (still cited above).
>>
>>Not at all.  You said:
>>
>>>>>>> The only case where you need to remove the rest of the search
>>>>>>> order (and therefore save and restore the old search order) is
>>>>>>> if you are using names that are not in any wordlist that you
>>>>>>> know is guaranteed to be on the stack, and you want a guarantee
>>>>>>> that this name is not found.
>>
>>This is not the case here: you are using names that may (or may not)
>>be in any wordlist that you know is guaranteed to be on the stack.
>>That's the point; you don't know, so you have to trim.
> 
> Sorry, I totally fail to see what points you are trying to make.
> It's unclear what you mean with basically everything in the last
> paragraph.
>
> I could imagine a variety of interpretations of it that maybe make it
> consistent with what you write before, but discussing any one of them
> is pretty pointless, because it's probably not what you had in mind,
> and there are too many to sensibly discuss them all.
> 
> In any case, maybe you failed to understand the significance of "and
> you want a guarantee that this name is not found.".

Let's rewind:

The names in question may well be in a wordlist that you know is
guaranteed to be on the stack.  That's what you're worried about: you
want to make sure that if a name is found, it really is the unique
instance of that name in the wordlist you specify.

therefore

"you are using names that are *not* in any wordlist that you know is
guaranteed to be on the stack"

is false.

Andrew.

[toc] | [prev] | [next] | [standalone]

#14976 — Re: ALSO - anything better?

On Wednesday, August 15, 2012 5:21:42 PM UTC+2, Andrew Haley wrote:
[..]
> How can that possibly work?  You want to make sure that, if the word
> 
> is absent, the lookup will fail -- just like the Java example.

Isn't this what SEARCH-WORDLIST is for?

-marcel

[toc] | [prev] | [next] | [standalone]

#14993 — Re: ALSO - anything better?

mhx@iae.nl writes:
>On Wednesday, August 15, 2012 5:21:42 PM UTC+2, Andrew Haley wrote:
>[..]
>> How can that possibly work?  You want to make sure that, if the word
>> 
>> is absent, the lookup will fail -- just like the Java example.
>
>Isn't this what SEARCH-WORDLIST is for?

When you use the text interpreter, it searches the whole search order.
SEARCH-WORDLIST does not come into play there.

- 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/

[toc] | [prev] | [next] | [standalone]

#14997 — Re: ALSO - anything better?

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: ALSO - anything better?

> mhx@iae.nl writes:
>>On Wednesday, August 15, 2012 5:21:42 PM UTC+2, Andrew Haley wrote:
[..]
>>> How can that possibly work?  You want to make sure that, if the word
>>> is absent, the lookup will fail -- just like the Java example.

>>Isn't this what SEARCH-WORDLIST is for?

> When you use the text interpreter, it searches the whole search order.
> SEARCH-WORDLIST does not come into play there.

I commented on the idea of wanting a unique word, that resides 
in a known wordlist (fully-qualified name"). I have never had this problem 
(except in a metacompiler, where I don't need a general and portable 
solution). Therefore, a quick-fix like 

: ... s" ape" wid search-wordlist 0= throw  locals| xt |  
      ... xt execute .. ;

seems appropriate. In my metacompiler I have 'smart' wordlists that 
(roughly) push themselves, execute/compile the next word, and pop the 
search-order again.

-marcel

[toc] | [prev] | [next] | [standalone]

#15009 — Re: ALSO - anything better?

mhx@iae.nl (Marcel Hendrix) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: ALSO - anything better?
>
>> mhx@iae.nl writes:
>>>On Wednesday, August 15, 2012 5:21:42 PM UTC+2, Andrew Haley wrote:
>[..]
>>>> How can that possibly work?  You want to make sure that, if the word
>>>> is absent, the lookup will fail -- just like the Java example.
>
>>>Isn't this what SEARCH-WORDLIST is for?
>
>> When you use the text interpreter, it searches the whole search order.
>> SEARCH-WORDLIST does not come into play there.
>
>I commented on the idea of wanting a unique word, that resides 
>in a known wordlist (fully-qualified name"). I have never had this problem 
>(except in a metacompiler, where I don't need a general and portable 
>solution). Therefore, a quick-fix like 
>
>: ... s" ape" wid search-wordlist 0= throw  locals| xt |  
>      ... xt execute .. ;
>
>seems appropriate.

Hmm, ok.  Yes, in text-interpreted words we do not have this problem,
because we only write words there that we know are in the search
order, so getting a guaranteed fail for an absent word is not needed.

The only exception may be when using [DEFINED] and friends (and even
there it's not usually the case), and if we want that property, we can
replace the use of DEFINED with a use of SEARCH-WORDLIST, yes.

- 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/

[toc] | [prev] | [next] | [standalone]

#14988 — Re: ALSO - anything better?

Anton Ertl wrote:
> "Ed" <invalid@nospam.com> writes:
> > ...
> >Whether one searches by stacking vocabs, or explicitly executing
> >them as required, the result should be the same.  No?
>
> No.  See below.
> ...

Apparently it sufficed LMI.

After further research I found LMI has the primitive 'find' - which takes
an arbitrary number of wids and searches them.  FIND however uses
just context current forth.

> >Stacking vocabs has the same issue as too many items on the
> >data stack - it's difficult to keep track.
>
> And yet we use a stack, and not two registers plus a constant (which
> would be the equivalent of "context current forth").

I don't like arbitrarily long stacks with strange behaviours whose
contents I barely remember after several pages of code and ALSO
PREVIOUS machinations.

LMI saw ONLY ALSO as "brain damaged" and made it plain they
would not implement ANS if forced upon them.  Those interested
can read statements by the key players.  Google the document
"bestof04.91"

Since then I note vendors and others have have added  +ORDER
-ORDER  to the list.  This monster just keeps growing new heads.

[toc] | [prev] | [next] | [standalone]

#14990 — Re: ALSO - anything better?

On Aug 16, 5:08 am, "Ed" <inva...@nospam.com> wrote:
> Anton Ertl wrote:
> > "Ed" <inva...@nospam.com> writes:
> > > ...
> > >Whether one searches by stacking vocabs, or explicitly executing
> > >them as required, the result should be the same.  No?
>
> > No.  See below.
> > ...
>
> Apparently it sufficed LMI.

Who?

>
> After further research I found LMI has the primitive 'find' - which takes
> an arbitrary number of wids and searches them.  FIND however uses
> just context current forth.
>
> > >Stacking vocabs has the same issue as too many items on the
> > >data stack - it's difficult to keep track.
>
> > And yet we use a stack, and not two registers plus a constant (which
> > would be the equivalent of "context current forth").
>
> I don't like arbitrarily long stacks with strange behaviours whose
> contents I barely remember after several pages of code and ALSO
> PREVIOUS machinations.
>
> LMI saw ONLY ALSO as "brain damaged" and made it plain they
> would not implement ANS if forced upon them.  Those interested
> can read statements by the key players.  Google the document
> "bestof04.91"

Here, since you're too lazy to cut & paste it, or even give a decent
link;

 1) There is no standard way to save the existing search order, set
the
    search order to a particular value, and later restore the search
order.

 2) In the common implementations, it is easy to get in a situation
where
    the same vocabulary is searched twice.  This is an implementation
problem,
    not a specification problem, and it's only bad effect is slower
    compilation, but some people criticise it anyway.

 3) A program has no standard way of knowing how many vocabularies it
can
    add to the search order before the search order data structure
overflows
    and the system crashes.

 4) Many people think that the behavior of the search order as a
"funny
    stack" (where the execution of a vocabulary *replaces* the top of
the
    stack) is screwy.

 5) There is no portable way of testing what is in the search order.

 6) There is no portable way of removing a particular vocabulary from
the
    search order.

Summarised by Mitch Bradley and agreed as the issues by Gary Smith of
LMI.

>
> Since then I note vendors and others have have added  +ORDER
> -ORDER  to the list.  This monster just keeps growing new heads.

Given Mitch's summary, which do you feel are worth addressing that
haven't been addressed already? Supplemental question: do we need to
take account of a 22 year old conversation and objections from a
company that has long disappeared?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web