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

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

alternatives to `find`

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

Contents

  alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-21 20:09 +0000
    Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-22 05:54 +0000
      Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-22 15:37 +0000
        Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-22 22:03 -0700
          Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-22 22:14 -0700
            Re: alternatives to `find` hughaguilar96@gmail.com - 2015-10-23 01:28 -0700
            Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-23 12:12 +0000
            Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 11:39 +0000
              Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-26 05:14 -0700
          Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-23 12:30 +0000
            Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-23 22:52 -0700
              Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-23 23:14 -0700
              Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-24 11:15 +0000
                Re: alternatives to `find` Coos Haak <chforth@hccnet.nl> - 2015-10-24 14:34 +0200
                  Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-24 14:45 +0000
                    Re: alternatives to `find` Coos Haak <chforth@hccnet.nl> - 2015-10-24 17:23 +0200
              Preserving standard and common use names (Re: alternatives to `find`) Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-24 11:53 +0000
                Re: Preserving standard and common use names (Re: alternatives to `find`) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-24 22:48 -0700
                  Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-24 21:05 -1000
                    Re: Preserving standard and common use names (Re: alternatives to `find`) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-25 01:34 -0700
                      Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-24 22:45 -1000
                      Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-25 09:16 +0000
                        Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-25 08:46 -1000
                        Re: Preserving standard and common use names (Re: alternatives to `find`) hughaguilar96@gmail.com - 2015-10-25 21:31 -0700
                      Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-25 18:50 +0100
                      Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-26 01:57 -0700
                        Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-26 02:07 -0700
                          Re: Preserving standard and common use names (Re: alternatives to `find`) Ron Aaron <rambamist@gmail.com> - 2015-10-26 11:14 +0200
                          Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-26 04:18 -0700
                          Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-26 09:22 -1000
                            Re: Preserving standard and common use names (Re: alternatives to `find`) hughaguilar96@gmail.com - 2015-10-26 21:34 -0700
                        Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 10:58 +0000
                          Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-26 05:59 -0700
                            Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-26 14:58 +0100
                            Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-27 17:09 +0000
                              Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 12:50 +0000
                                Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-28 15:56 +0000
                                Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-28 10:31 -0700
                                  Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-28 19:26 +0100
                                    Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-28 12:37 -0700
                                  Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:03 +0000
                                    Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-28 16:21 -0700
                                Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-28 20:37 +0100
                                  Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:13 +0000
                                    Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-29 03:01 +0100
                                      Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:04 +0000
                                        Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 15:29 +0000
                                          Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-30 04:17 -0700
                                            Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-30 11:36 +0000
                                              Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 15:25 +0000
                                                Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-31 20:34 +0000
                                            Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-30 20:51 +0000
                                              Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-11-02 01:39 -0800
                                                Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 11:12 +0000
                                                Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-02 12:09 +0000
                                                  Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-11-02 05:09 -0800
                                                  Re: Preserving standard and common use names (Re: alternatives to `find`) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 06:23 -0800
                                                Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 14:39 +0000
                                                Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-20 16:20 +0000
                                                  Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-11-21 00:26 -0800
                                            Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 15:03 +0000
                                              Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:35 +0000
                                                Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-01 14:07 +0000
                                                  Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-01 21:05 +0100
                                            Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:31 +0000
                                              Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 20:33 +0100
                                        Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-29 22:27 +0100
                                      Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 13:19 +0000
                                    Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 10:00 +0000
                                      Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 13:29 +0000
                                        Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 14:04 +0000
                                          Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 16:29 +0000
                                            Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:42 +0000
                                      Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:13 +0000
                                        Re: Preserving standard and common use names (Re: alternatives to `find`) mhx@iae.nl - 2015-10-29 12:19 -0700
                                          Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 14:12 +0000
                                            Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:49 +0000
                                              Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-31 10:33 -0700
                                              Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-01 14:14 +0000
                    Re: Preserving standard and common use names (Re: alternatives to `find`) hughaguilar96@gmail.com - 2015-10-25 21:52 -0700
            Re: alternatives to `find` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-10-30 12:30 +0000
        Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 11:47 +0000
    Re: alternatives to `find` Chris Curl <ccurl609@gmail.com> - 2015-11-02 06:17 -0800
      Re: alternatives to `find` Mark Wills <markwills1970@gmail.com> - 2015-11-02 06:35 -0800
      Re: alternatives to `find` Coos Haak <chforth@hccnet.nl> - 2015-11-02 15:45 +0100
        Re: alternatives to `find` Chris Curl <ccurl609@gmail.com> - 2015-11-02 07:17 -0800
          Re: alternatives to `find` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 19:39 +0000
            Re: alternatives to `find` Mark Wills <markwills1970@gmail.com> - 2015-11-02 12:19 -0800
            Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:31 +0000
              Re: alternatives to `find` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 21:11 +0000
                MOVE and CMOVE speed (was: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:52 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#42733 — alternatives to `find`

Instead of the standard `find` (that is still provided as an option in
the library of my system, with `word`) I use a word that expects an
address and a count instead of a counted string.  At the moment I call
it `find-name`.

So far I've tried three versions:

  find-name  ( ca len -- 0 | cfa 1 | cfa -1 )
  find-name  ( ca len -- ca len 0 | cfa 1 | cfa -1 )
  find-name  ( ca len -- x 0 | cfa 1 | cfa -1 )

The first two versions were abandoned soon because they return a variable
number of items, what is inconvenient.

Now, in order to finish the implementation of `compile-only`, I'm migrating to
a new version of `find-name`, inspired by eForth's `sfind`:

  find-name  ( ca len -- ca len false | cfa b true )

where _b_ is the length byte of the name field, containing the smudge,
precedence and compile-only bits.

I'm considering also this possible variant:

  find-name  ( ca len -- ca len false | cfa nfa true )

This way `immediate?` and `compile-only?` (used by `interpret` in this
system) would be more versatile: they would expect a nfa, not a length
byte.

Finally, I'm considering Gforth's `find-name`:

  find-name  ( ca len -- nfa | 0 )

and get everything else from the nfa.

Eventually, the decision will depend on the result of some benchmarks,
and the used memory (note it's an 8-bit platform). In fact at the moment
any version of `find-name` can be selected, with conditional compilation
of the kernel.

Any advice, example or opinion on alternatives to `find` (common use
names and returned items)?

-- 
Marcos Cruz
http://programandala.net

[toc] | [next] | [standalone]

#42748

Marcos Cruz <use_the_contact_page@programandala.net> writes:
>  find-name  ( ca len -- 0 | cfa 1 | cfa -1 )

Gforth has this under the name SFIND, but it's marked as obsolete.

>Finally, I'm considering Gforth's `find-name`:
>
>  find-name  ( ca len -- nfa | 0 )
>
>and get everything else from the nfa.

If you do something else, I hope you will use a different name.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#42759

En/Je/On 2015-10-22, Anton Ertl <anton@mips.complang.tuwien.ac.at>
escribió/skribis/wrote:

>>Finally, I'm considering Gforth's `find-name`:
>>
>>  find-name  ( ca len -- nfa | 0 )
>>
>>and get everything else from the nfa.
>
> If you do something else, I hope you will use a different name.

`find-name` is not in the standard, but is it used the same way by other
widely known systems? I didn't check it.

Anyway, I think it's a good name to return just a name token, as in
Gforth.  `find-word` seems a better alternative for a different stack
effect.

-- 
Marcos Cruz
http://programandala.net

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

#42763

joi, 22 octombrie 2015, 18:37:37 UTC+3, Marcos Cruz a scris:
> En/Je/On 2015-10-22, Anton Ertl <anton@mips.complang.tuwien.ac.at>
> escribió/skribis/wrote:
> 
> >>Finally, I'm considering Gforth's `find-name`:
> >>
> >>  find-name  ( ca len -- nfa | 0 )
> >>
> >>and get everything else from the nfa.
> >
> > If you do something else, I hope you will use a different name.
> 
> `find-name` is not in the standard, but is it used the same way by other
> widely known systems? I didn't check it.
> 
> Anyway, I think it's a good name to return just a name token, as in
> Gforth.  `find-word` seems a better alternative for a different stack
> effect.
> 
> -- 
> Marcos Cruz
> http://programandala.net

In my system I have SEARCH which returns the dictionary pointer (the so 
called "name token"). Based on it and knowning the dictionary entry 
structure, you can get all info about a word.

I also have SEARCHWORDLIST that searches in a wordlist given as a parameter.

Symetrically I have FIND and FINDWORDLIST, but these can be derived from the SEARCH words (even ' (tick) can be derived from SEARCH).

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

#42764

vineri, 23 octombrie 2015, 08:03:22 UTC+3, Raimond Dragomir a scris:
> joi, 22 octombrie 2015, 18:37:37 UTC+3, Marcos Cruz a scris:
> > En/Je/On 2015-10-22, Anton Ertl <anton@mips.complang.tuwien.ac.at>
> > escribió/skribis/wrote:
> > 
> > >>Finally, I'm considering Gforth's `find-name`:
> > >>
> > >>  find-name  ( ca len -- nfa | 0 )
> > >>
> > >>and get everything else from the nfa.
> > >
> > > If you do something else, I hope you will use a different name.
> > 
> > `find-name` is not in the standard, but is it used the same way by other
> > widely known systems? I didn't check it.
> > 
> > Anyway, I think it's a good name to return just a name token, as in
> > Gforth.  `find-word` seems a better alternative for a different stack
> > effect.
> > 
> > -- 
> > Marcos Cruz
> > http://programandala.net
> 
> In my system I have SEARCH which returns the dictionary pointer (the so 
> called "name token"). Based on it and knowning the dictionary entry 
> structure, you can get all info about a word.
> 
> I also have SEARCHWORDLIST that searches in a wordlist given as a parameter.
> 
> Symetrically I have FIND and FINDWORDLIST, but these can be derived from the SEARCH words (even ' (tick) can be derived from SEARCH).

And BTW, I don't have counted strings at all, all my strings are S" strings,
always given as "adr len" pairs. Even the internal parser and interpreter
work with such strings (traditionally they work with counted strings).

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

#42766

On Thursday, October 22, 2015 at 10:14:36 PM UTC-7, Raimond Dragomir wrote:
> And BTW, I don't have counted strings at all, all my strings are S" strings,
> always given as "adr len" pairs. Even the internal parser and interpreter
> work with such strings (traditionally they work with counted strings).

I think this is a good idea. Consistency is a virtue.

ANS-Forth has two different ways to represent strings --- the language is gratuitously complicated (some words work with C" strings and other words work with S" strings; I can't remember which are which without looking them up in the ANS-Forth document every time that I use them) --- obviously C" should be discarded as it is an artifact from the 1970s computers in which memory was limited to a few KB (if you only have 5KB of RAM and a cassette-drive for mass-storage like in the Commodore Vic-20, you have to only process small amounts of data).

It is also a good idea to have a doubles-stack separate from the singles-stack --- intermixing single-cell and double-cell data on the same stack is the #1 cause of the unreadable stack-juggling that ANS-Forth is notorious for --- in the 1970s this was not realistic because the PDP-11 had only 8 registers and there wasn't any register available for a doubles-stack pointer --- but register-starvation hasn't been a problem since the introduction of the MC68000 in 1979 that had 16 registers.

All in all, ANS-Forth looks like it was designed for the 1970s computers --- I wouldn't even give it credit for being appropriate to the 1980s computers. Forth-83 wasn't any good either. Every Forth Standard (with a capital 'S') has been like a boat anchor chained to the Forth programmer's ankle, anchoring him firmly in the mid-1970s.

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

#42767

En/Je/On 2015-10-23, Raimond Dragomir <raimond.dragomir@gmail.com>
escribió/skribis/wrote:

> And BTW, I don't have counted strings at all, all my strings are S"
> strings, always given as "adr len" pairs. Even the internal parser and
> interpreter work with such strings (traditionally they work with
> counted strings).

Same here, no counted strings for parsing and searching words. It's more
efficient (especially in a slow 8-bit system) because there's no need to
move things around: you can use the stream source directly.

I moved `find` and `word` to the library of the system.

-- 
Marcos Cruz
http://programandala.net

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

#42839

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>And BTW, I don't have counted strings at all, all my strings are S" strings=
>,
>always given as "adr len" pairs. Even the internal parser and interpreter
>work with such strings

That's nothing special.  Gforth has done that for decades, and it's
not the only one AFAIK.  System implementations do not need to be
standard-conforming programs, so of course they do not need to use the
legacy FIND interface.  It's a shame that we could not agree on a
modern replacement for FIND in Forth-2012 (or since then);
unfortunately there is too much contention on topics related to that.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#42844

luni, 26 octombrie 2015, 13:45:51 UTC+2, Anton Ertl a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >And BTW, I don't have counted strings at all, all my strings are S" strings=
> >,
> >always given as "adr len" pairs. Even the internal parser and interpreter
> >work with such strings
> 
> That's nothing special.  Gforth has done that for decades, and it's
> not the only one AFAIK.  

I know that, I didn't pretend this is my invention.

> standard-conforming programs, so of course they do not need to use the
> legacy FIND interface.  It's a shame that we could not agree on a
> modern replacement for FIND in Forth-2012 (or since then);

I agree...

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

#42768

En/Je/On 2015-10-23, Raimond Dragomir <raimond.dragomir@gmail.com>
escribió/skribis/wrote:

> In my system I have SEARCH which returns the dictionary pointer (the
> so called "name token"). Based on it and knowning the dictionary entry
> structure, you can get all info about a word.

So its stack effect is 

	( ca len -- nt | 0 )

That's the latest option I've implemented, after Gforth's `find-name`,
So far it seems simpler and more versatile than previous alternatives I
tried.

> I also have SEARCHWORDLIST that searches in a wordlist given as a
> parameter.

	( ca len wid -- nt | 0 )

Is it?

> Symetrically I have FIND and FINDWORDLIST, but these can be derived
> from the SEARCH words

What are their stack effects?

-- 
Marcos Cruz
http://programandala.net

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

#42770

vineri, 23 octombrie 2015, 15:30:40 UTC+3, Marcos Cruz a scris:
> En/Je/On 2015-10-23, Raimond Dragomir <raimond.dragomir@gmail.com>
> escribió/skribis/wrote:
> 
> > In my system I have SEARCH which returns the dictionary pointer (the
> > so called "name token"). Based on it and knowning the dictionary entry
> > structure, you can get all info about a word.
> 
> So its stack effect is 
> 
> 	( ca len -- nt | 0 )
> 
> That's the latest option I've implemented, after Gforth's `find-name`,
> So far it seems simpler and more versatile than previous alternatives I
> tried.
> 
> > I also have SEARCHWORDLIST that searches in a wordlist given as a
> > parameter.
> 
> 	( ca len wid -- nt | 0 )
> 
> Is it?
> 
> > Symetrically I have FIND and FINDWORDLIST, but these can be derived
> > from the SEARCH words
> 
> What are their stack effects?
> 
> -- 
> Marcos Cruz
> http://programandala.net

Exactly:

searchwordlist ( adr len wid -- 0 | nt )
search ( adr len -- 0 | nt )
findwordlist ( adr len wid -- 0 | xt 1 | xt 2 )
find ( adr len -- 0 | xt 1 | xt 2 )

find and findwordlist return 1 for "normal" words (non-immediate) and 2 for 
immediate words. It was just easy to return 2 because it is the bitmask value
for the immediate flag...

Anyway, find and findwordlist are defined in high level forth based on search
and searchwordlist. I never used them. I always use search.
It's so trivial to get anything about a word after you have the nt...
For example:

bl parse search   \ nt
dict.addr @       \ xt

or:
bl parse search   \ nt
dict.type c@ DF_IMMED and   \ immed bitmask

etc.
Of course there need to be an initial check if nt is zero or not,
but that's the basic idea.

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

#42771

sâmbătă, 24 octombrie 2015, 08:52:47 UTC+3, Raimond Dragomir a scris:
> vineri, 23 octombrie 2015, 15:30:40 UTC+3, Marcos Cruz a scris:
> > En/Je/On 2015-10-23, Raimond Dragomir <raimond.dragomir@gmail.com>
> > escribió/skribis/wrote:
> > 
> > > In my system I have SEARCH which returns the dictionary pointer (the
> > > so called "name token"). Based on it and knowning the dictionary entry
> > > structure, you can get all info about a word.
> > 
> > So its stack effect is 
> > 
> > 	( ca len -- nt | 0 )
> > 
> > That's the latest option I've implemented, after Gforth's `find-name`,
> > So far it seems simpler and more versatile than previous alternatives I
> > tried.
> > 
> > > I also have SEARCHWORDLIST that searches in a wordlist given as a
> > > parameter.
> > 
> > 	( ca len wid -- nt | 0 )
> > 
> > Is it?
> > 
> > > Symetrically I have FIND and FINDWORDLIST, but these can be derived
> > > from the SEARCH words
> > 
> > What are their stack effects?
> > 
> > -- 
> > Marcos Cruz
> > http://programandala.net
> 
> Exactly:
> 
> searchwordlist ( adr len wid -- 0 | nt )
> search ( adr len -- 0 | nt )
> findwordlist ( adr len wid -- 0 | xt 1 | xt 2 )
> find ( adr len -- 0 | xt 1 | xt 2 )
> 
> find and findwordlist return 1 for "normal" words (non-immediate) and 2 for 
> immediate words. It was just easy to return 2 because it is the bitmask value
> for the immediate flag...
> 
> Anyway, find and findwordlist are defined in high level forth based on search
> and searchwordlist. I never used them. I always use search.
> It's so trivial to get anything about a word after you have the nt...
> For example:
> 
> bl parse search   \ nt
> dict.addr @       \ xt
> 
> or:
> bl parse search   \ nt
> dict.type c@ DF_IMMED and   \ immed bitmask
> 
> etc.
> Of course there need to be an initial check if nt is zero or not,
> but that's the basic idea.

LOL, it's clear that I have not used the find/findwordlist...
The immediate bit is not 2 anymore...
Anyway, here are the latest find and findwordlist definitions:

: <find> \ nt -- 0 | xt 1 | xt 2
  dup dict.addr @
  swap dict.type c@ DF_IMMED and if 2 else 1 then ;

: find \ adr len -- 0 | xt 1 | xt 2
  search dup 0= if exit then <find> ;

: findwordlist \ adr len wid -- 0 | xt 1 | xt 2
  searchwordlist dup 0= if exit then <find> ;

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

#42772

En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
escribió/skribis/wrote:

> searchwordlist ( adr len wid -- 0 | nt )
> search ( adr len -- 0 | nt )
> findwordlist ( adr len wid -- 0 | xt 1 | xt 2 )
> find ( adr len -- 0 | xt 1 | xt 2 )
>
> It's so trivial to get anything about a word after you have the nt...

After trying different methods, I think your `search`, equivalent to
Gforth's `find-name`, keeps things simpler and is more versatile that
other alternatives.

-- 
Marcos Cruz
http://programandala.net

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

#42774

Op Sat, 24 Oct 2015 11:15:49 +0000 (UTC) schreef Marcos Cruz:

> En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
> escribió/skribis/wrote:
> 
>> searchwordlist ( adr len wid -- 0 | nt )
>> search ( adr len -- 0 | nt )
>> findwordlist ( adr len wid -- 0 | xt 1 | xt 2 )
>> find ( adr len -- 0 | xt 1 | xt 2 )
>>
>> It's so trivial to get anything about a word after you have the nt...
> 
> After trying different methods, I think your `search`, equivalent to
> Gforth's `find-name`, keeps things simpler and is more versatile that
> other alternatives.

Here begins a word name clash. In the String word set there is a
word called STRING (17.6.1.2191) that has nothing to do with
word lists but searches a substring in a substring.
( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 flag )

groet Coos

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

#42775

Coos Haak <chforth@hccnet.nl> writes:
>Op Sat, 24 Oct 2015 11:15:49 +0000 (UTC) schreef Marcos Cruz:
>
>> En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
>> escribió/skribis/wrote:
>>> search ( adr len -- 0 | nt )
...
>Here begins a word name clash. In the String word set there is a
>word called STRING (17.6.1.2191) that has nothing to do with
>word lists but searches a substring in a substring.
>( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 flag )

You mean the word SEARCH.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#42776

Op Sat, 24 Oct 2015 14:45:22 GMT schreef Anton Ertl:

> Coos Haak <chforth@hccnet.nl> writes:
>>Op Sat, 24 Oct 2015 11:15:49 +0000 (UTC) schreef Marcos Cruz:
>>
>>> En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
>>> escribió/skribis/wrote:
>>>> search ( adr len -- 0 | nt )
> ...
>>Here begins a word name clash. In the String word set there is a
>>word called STRING (17.6.1.2191) that has nothing to do with
>>word lists but searches a substring in a substring.
>>( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 flag )
> 
> You mean the word SEARCH.
> 
> - anton

Of course

groet Coos

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

#42773 — Preserving standard and common use names (Re: alternatives to `find`)

En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
escribió/skribis/wrote:

> search ( adr len -- 0 | nt )
> find ( adr len -- 0 | xt 1 | xt 2 )

By the way, even if a system doesn't follow any standard, I think
preserving standard and common use names is a good idea.  It makes life
a bit easier when porting or even just reading code.

Since you use `search` and `find` with non-standard functions it's
obvious this point is unimportant for you. What is your opinion?

-- 
Marcos Cruz
http://programandala.net

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

#42783 — Re: Preserving standard and common use names (Re: alternatives to `find`)

sâmbătă, 24 octombrie 2015, 14:53:18 UTC+3, Marcos Cruz a scris:
> En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
> escribió/skribis/wrote:
> 
> > search ( adr len -- 0 | nt )
> > find ( adr len -- 0 | xt 1 | xt 2 )
> 
> By the way, even if a system doesn't follow any standard, I think
> preserving standard and common use names is a good idea.  It makes life
> a bit easier when porting or even just reading code.
> 
> Since you use `search` and `find` with non-standard functions it's
> obvious this point is unimportant for you. What is your opinion?
> 

My opinion is that the standard is full of inconsistencies, and it stands in my way. So I ignore it most of the time.

Yes, SEARCH is in the string wordset. Do you think it is a good name for a string wordset word? has the SEARCH word anything in common with a string thing? No. It is too general, it deserves a more "system" duty. Probably when the people needed a word for a string search they were unlucky because FIND was taken... so they named it SEARCH.

Let's take another example: in the search-order word set, there is SEARCH-WORDLIST. Don't you think it should have been more of a FIND-WORDLIST ? Yup, 
it works with an "adr len" string, not a counted string... but, on the other hand, why FIND (in the current form requiring counted strings) still exists in the standard?

Why should I care about of such a standard? My system is more clean, more clear, more consistent with some principles, and it is probably 90-95% "standard".


> -- 
> Marcos Cruz
> http://programandala.net

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

#42784 — Re: Preserving standard and common use names (Re: alternatives to `find`)

On 10/24/15 7:48 PM, Raimond Dragomir wrote:
> sâmbătă, 24 octombrie 2015, 14:53:18 UTC+3, Marcos Cruz a scris:
>> En/Je/On 2015-10-24, Raimond Dragomir <raimond.dragomir@gmail.com>
>> escribió/skribis/wrote:
>>
>>> search ( adr len -- 0 | nt )
>>> find ( adr len -- 0 | xt 1 | xt 2 )
>>
>> By the way, even if a system doesn't follow any standard, I think
>> preserving standard and common use names is a good idea.  It makes life
>> a bit easier when porting or even just reading code.
>>
>> Since you use `search` and `find` with non-standard functions it's
>> obvious this point is unimportant for you. What is your opinion?
>>
>
> My opinion is that the standard is full of inconsistencies, and it stands in my way. So I ignore it most of the time.
>
> Yes, SEARCH is in the string wordset. Do you think it is a good name for a string wordset word? has the SEARCH word anything in common with a string thing? No. It is too general, it deserves a more "system" duty. Probably when the people needed a word for a string search they were unlucky because FIND was taken... so they named it SEARCH.
>
> Let's take another example: in the search-order word set, there is SEARCH-WORDLIST. Don't you think it should have been more of a FIND-WORDLIST ? Yup,
> it works with an "adr len" string, not a counted string... but, on the other hand, why FIND (in the current form requiring counted strings) still exists in the standard?
>
> Why should I care about of such a standard? My system is more clean, more clear, more consistent with some principles, and it is probably 90-95% "standard".

If you don't want to write programs for other people to use, or use 
programs other people have written, or expect anyone other than yourself 
to use your system, a standard has very little value. Enjoy.

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]

#42785 — Re: Preserving standard and common use names (Re: alternatives to `find`)

> If you don't want to write programs for other people to use, or use 
> programs other people have written, or expect anyone other than yourself 
> to use your system, a standard has very little value. Enjoy.

A weak standard doesn't provide these things either.
It's not my fault that the forth standard is so weak and obsolete and
so inconsistent (counted strings; do loops, >r, R>, locals, all clashing
on the return stack, no control stack, etc).
I said my forth is probably 90% standard. It should be usable by any
forther right away, even to the most seasoned ones...
I would like to see a new standard that is let say 90% of the current one,
that will look more like a modern language (and not one of the 70's)
but it doesn't seem that anyone will have such a courage. All will come
(as always) with the same excuse of maintaining legacy code...
Legacy code is legacy code, it will always have the 94 standard and the
current compliant systems and compilers. New code can have a fresh start,
but nobody is interested. In fact, the sad thing is that forth has lost
the critical mass some time ago and it's really dying.

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web