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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

On Wed, 28 Oct 2015 10:31:50 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>stephen@mpeforth.com (Stephen Pelc) writes:
>> In my particular case, I see that Cortex-M4F provides single-precision
>> (32 bit) floating point instructions.
>
>I thought the M4F was being followed on by the M7, which also supports
>double precision.

You have to read the ARM documents *carefully*, not the sales
literature. Double precision FP is an option on Cortex-M4F, but
so far no-one has implemented it. According to ARM DDI 0489b, this is
still true for Cortex-M7. See Table 8.1.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

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

stephen@mpeforth.com (Stephen Pelc) writes:
> You have to read the ARM documents *carefully*, not the sales
> literature. Double precision FP is an option on Cortex-M4F, but
> so far no-one has implemented it. According to ARM DDI 0489b, this is
> still true for Cortex-M7. See Table 8.1.

Hmmm, ok.  It looks like the M7 in the STMF7 Discovery board only has
single precision too.  What a disappointment.

There is an article in German that discusses the M7 FPU but I haven't
tried to decipher it:

http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/112869/2/

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

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

Stephen Pelc wrote:
> In my particular case, I see that Cortex-M4F provides single-precision
> (32 bit) floating point instructions. Having a separate FP stack
> implemented efficiently costs an extra register and careful memory
> control. As Klaus showed at EuroForth 2015, 32 bit FP has a point. It
> will become more common in the future. A shared data stack is looking
> like a good compromise.

Are you sure?  The M4F has 32 floating point registers, and Thumb 2 allows 
you to access all 16 integer registers (including SP+LP+PC, so 13 GP and 3 
special purpose registers).  When you generate code for that, you have to 
keep in mind that all floating point values need to go to the 32 Sx 
registers, and all integer values need to go to the 13 (excluding the 
special purpose registers) integer registers.  Easy to do with a separated 
floating point stack... very difficult with a shared stack.

The deeper problem is that you want to have choices which are incompatible 
with each other stamped as "standard system".  If you want libraries, stick 
to one choice that allows people to write programs for.  Programs that run 
on a number of different processors.

As a result, one or the other processor might suffer a little bit from 
making that particular choice.  A few special-purpose processors might 
suffer more.  But if you undefine the actual language, and say "well, it 
might be separate or it might be combined, deal with that, programmer!", 
then you just won't get portable libraries.

Nobody wants to write programs for such a fucked up standard.  We had that 
situation since 1994, and everybody who wrote a portable library (not so 
many did) wrote it for separate stacks.

A standard is not just a means for system implementers to do whatever they 
want, and then still be able to call their system "standard".  Any decision 
you make for a standard should follow the idea of Kant's categorical 
imperative, "Act only according to that maxim whereby you can, at the same 
time, will that it should become a universal law."

If you can't make an universal decision on a particular implementation 
choice, at least provide an abstraction so that application writers can use 
that abstraction.  E.g. CELLS and CELL+ for the size of the cell.  Or 
COMPILE, to deal with compilation of xts.  Abstractions may incur costs; we 
want to avoid abstractions where not necessary, so for all choices where an 
abstraction is not necessary or not possible, we deal with it by nailing 
down that choice.

The separated FP stack is such an abstraction.  It sometimes costs you a 
valueable register, and gives you portable programs between different CPUs.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

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

On Wed, 28 Oct 2015 20:37:17 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>Nobody wants to write programs for such a fucked up standard.  We had that 
>situation since 1994, and everybody who wrote a portable library (not so 
>many did) wrote it for separate stacks.

True, which is why we have written six ARM/Cortex FP packages this
year to investigate the problem. From a software writer's point of
view, a separate FP stack wins every time for ease of use.

However, you totally ignore my main point, which is that sometimes 
standards just get it wrong. In such cases we should just admit it and
change the standard. If I knew then what I know about 32 bit CPUs and
and 32 bit FP, I would not have accepted the combined/separate FP
stack argument without a *lot* more consideration.

People have already made a similar point to me about the byte
addressed CPU assumption and 1 CHARS = 1. More thought needed.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

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

Stephen Pelc wrote:

> On Wed, 28 Oct 2015 20:37:17 +0100, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>>Nobody wants to write programs for such a fucked up standard.  We had that
>>situation since 1994, and everybody who wrote a portable library (not so
>>many did) wrote it for separate stacks.
> 
> True, which is why we have written six ARM/Cortex FP packages this
> year to investigate the problem. From a software writer's point of
> view, a separate FP stack wins every time for ease of use.

Yes.  Next is a combined stack with one cell per floating point, still ok.  
Combined stack with double- or quad-cell FP, much worse.  But the worst 
thing is to write a program that works on both combined and separate stacks.  
That's really hard.

bigForth's 68k floating point library (no coprocessor on the 68k) had a 
compile time switch to select between shared and separate floating point.  I 
only used it in separate FP mode, except for testing that everything works 
fine in combined mode.  The 386 port didn't keep that, because there, a 
coprocessor was available.

Apparently, you have enough time to write more than one FP package.  So for 
standard programs, you can have a separate stack FP package, and for non-
standard specially optimized for one particular platform, you can offer the 
combined one, which gives you (really? Benchmark results, please) an edge.

Then your customers can decide whether they want the standard package or the 
non-standard combined package, just like on VFX they can decide to load the 
32 bit combined stack FP library or the one of the other two, which are both 
separate stack.

If you load the combined stack FP library, you have a standard system with 
an environmental limitation that many standard programs aren't written for.  
That's all, and it won't change if we revise the standard.

> However, you totally ignore my main point, which is that sometimes
> standards just get it wrong.

Yes.  The Forth-94 standard got it wrong.  Nobody wanted to write for a 
standard where you have a choice.

> In such cases we should just admit it and
> change the standard. If I knew then what I know about 32 bit CPUs and
> and 32 bit FP, I would not have accepted the combined/separate FP
> stack argument without a *lot* more consideration.

I would expect considerably implementation problems if you don't know 
whether a value is an integer or a float until you actually process it and 
select the correct register where it should live (Sn for floats, Rn for 
ints) when you have a combined stack.  How did you deal with that?

Apart from experimental Forth CPUs or Forth-like CPUs there are no CPUs 
where floating point and integer unit share the register file.

If you have written 6 FP packages, you should be able to quantize the 
benefit of the unified stack, in terms of benchmarks, and as well in terms 
of effort to rewrite and test software for that specific model.  Does it pay 
off?

You had a 32 bit shared stack floating point version on x86 for many years, 
it was there to support OpenGL, before you changed the extern: interface to 
take floating point parameters from the FP stack (a change that came from 
the MINOS port).

> People have already made a similar point to me about the byte
> addressed CPU assumption and 1 CHARS = 1. More thought needed.

Same thing as above, people don't write programs for 1 CHARS <> 1, this time 
for slightly different reasons: It's not actually complicated to write, but 
it is hard to test with no popular Forth systems available where 1 CHARS <> 
1.  We probably should state that CHARS and CHAR+ are obsolescent, because 
they usually are NOOP and 1+, but if not, like with the combined FP stack, 
it's an obsolescent environmental restriction that 1 CHARS <> 1.  Then you 
have 10 years from the release of the next snapshot to think about it.

An obsolescent feature is not totally gone.  It's just supposed to be going 
away.  If it doesn't, like FORGET, people can decide to unobsolescent it the 
next round.  Or, if we do it as with the unified floating point stack, we 
could mark it as environmental restriction.  Only if this goes away, it will 
be completely out of the standard.  A system with an environmental 
restriction is not fully standard, but a subset of the standard.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

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

On Thu, 29 Oct 2015 03:01:29 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>Stephen Pelc wrote:
>
>> On Wed, 28 Oct 2015 20:37:17 +0100, Bernd Paysan <bernd.paysan@gmx.de>
>> wrote:
>> 
>>>Nobody wants to write programs for such a fucked up standard.  We had that
>>>situation since 1994, and everybody who wrote a portable library (not so
>>>many did) wrote it for separate stacks.
>> 
>> True, which is why we have written six ARM/Cortex FP packages this
>> year to investigate the problem. From a software writer's point of
>> view, a separate FP stack wins every time for ease of use.
>
>Yes.  Next is a combined stack with one cell per floating point, still ok.

The combined stack with one cell per floating point is a good design
compromise for 32 bit embedded systems ... but very bad if portability
from systems with 2+ cell floats and separate stacks is needed. With a
little reluctance, the separate stack is the way to go, especially
when taking the long-term view that double-precision IEEE is often
inadequate and that quad precision (128 bit) is a good objective.

>Apparently, you have enough time to write more than one FP package.  So for 
>standard programs, you can have a separate stack FP package, and for non-
>standard specially optimized for one particular platform, you can offer the 
>combined one, which gives you (really? Benchmark results, please) an edge.

There's 64 and 32 bit hardware FP and software FP for both combined
and separate stacks. The only way to find out which we liked was to do
it. However, we don't do enough FP work within MPE to say that there's
a body of critical FP use cases.

Anyone who has a performance-critical use of FP in an embedded system
is welcome to pass on any details should they allowed to.

>Then your customers can decide whether they want the standard package or the 
>non-standard combined package, just like on VFX they can decide to load the 
>32 bit combined stack FP library or the one of the other two, which are both 
>separate stack.

Ah, but if you read the docs you would know that VFX has only one lead
FP package, the others are on care and maintenance only.

>I would expect considerably implementation problems if you don't know 
>whether a value is an integer or a float until you actually process it and 
>select the correct register where it should live (Sn for floats, Rn for 
>ints) when you have a combined stack.  How did you deal with that?

Assume that the user knows the difference between + and F+. Is that
a suitably Bernd-ish response?

>If you have written 6 FP packages, you should be able to quantize the 
>benefit of the unified stack, in terms of benchmarks, and as well in terms 
>of effort to rewrite and test software for that specific model.  Does it pay 
>off?

Sometimes there's an itch you have to scratch (thank you, Hans) and
now (please) I'm done with FP for a few years.

>Same thing as above, people don't write programs for 1 CHARS <> 1, this time 
>for slightly different reasons: It's not actually complicated to write, but 
>it is hard to test with no popular Forth systems available where 1 CHARS <> 
>1.

Such systems exist. We have not had a discussion that concludes that
unpopular systems can be disenfranchised, nor IMHO should that
conclusion be reached at all.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

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

stephen@mpeforth.com (Stephen Pelc) writes:
>>Then your customers can decide whether they want the standard package or the 
>>non-standard combined package, just like on VFX they can decide to load the 
>>32 bit combined stack FP library or the one of the other two, which are both 
>>separate stack.
>
>Ah, but if you read the docs you would know that VFX has only one lead
>FP package, the others are on care and maintenance only.

This sounded much different when we discussed that it would be a good
idea to have an FP wordset loaded at the latest after the program asks
for FP.  Then you said that you have three FP packages, and you would
not know which one to load.

>>I would expect considerably implementation problems if you don't know 
>>whether a value is an integer or a float until you actually process it and 
>>select the correct register where it should live (Sn for floats, Rn for 
>>ints) when you have a combined stack.  How did you deal with that?
>
>Assume that the user knows the difference between + and F+. Is that
>a suitably Bernd-ish response?

Like many Bernd-ish responses, it does not satisfy me.  Please
elaborate.

>Sometimes there's an itch you have to scratch (thank you, Hans) and
>now (please) I'm done with FP for a few years.

You scratched it until it started bleeding, now you have to live with
that for a while.

>>Same thing as above, people don't write programs for 1 CHARS <> 1, this time 
>>for slightly different reasons: It's not actually complicated to write, but 
>>it is hard to test with no popular Forth systems available where 1 CHARS <> 
>>1.
>
>Such systems exist. We have not had a discussion that concludes that
>unpopular systems can be disenfranchised,

True, we did not have such a discussion in Forth200x, we just worked
with what we had from Forth-94 here:

|1.1 Purpose
|
|The purpose of this standard is to promote the portability of Forth
|programs for use on a wide variety of computing systems, to facilitate
|the communication of programs, programming techniques, and ideas among
|Forth programmers, and to serve as a basis for the future evolution of
|the Forth language.

Enfrenchisement of systems, whether popular or unpopular, is not among
the purposes of the standard.  It's about programs.  For comparison,
here's what the C99 rationale
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>
says on this subject:

|Existing code is important, existing implementations are not. 
[...]
|On the other hand, no one implementation was held up as the exemplar
|by which to define C. It was assumed that all existing
|implementations must change somewhat to conform to the Standard.

Which is quite a different approach than the one you advocate that no
Forth system must change, even if that means that there are hardly any
standard programs.

> nor IMHO should that
>conclusion be reached at all.

Let's have a standard that is the intersaction of all the systems
around that call themselves Forth.  So let's make an RfD that makes it
optional whether a system performs inclusive or exclusive or when
executing OR; and where IF may or may not pop it's argument off the
stack.  Note that exclusive or for OR and a non-popping IF are much
more popular than 1 CHARS > 1.  We don't want to discenfrenchise these
systems, do we?

Well, actually, I do.  I want a standard in which one can easily write
programs which can be ported from one system to the next without
changing a single line of code.  If there are systems that have to
change to reach this goal, then they should change.

Of course, we can continue to have a standard in which no "program of
any size" is conforming, just so that the most outlandish systems can
claim conformance, but what good would such a standard 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

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

On Thursday, 29 October 2015 16:13:15 UTC, Anton Ertl  wrote:
> Well, actually, I do.  I want a standard in which one can easily write
> programs which can be ported from one system to the next without
> changing a single line of code.  If there are systems that have to
> change to reach this goal, then they should change.
> 

In that case, I urge the committee to step up to the plate, make the
difficult, unpallatable, unpopular decisions, and give us a standard
"in which one can easily write programs which can be ported from one
system to the next without changing a single line of code."

You seem to be advocating what I have been saying for a while.

It's a different situation entirely for MPE though. For MPE, the 
only choice he would have in that circumstance, would be to
support two systems in parallel; ANS94 and xxxx (too late for 2000x).
His client with 1.2 million lines of code will not be happy if his
code breaks over night because VFX is brought into line with a new
standard; therefore MPE would have a create a new product, derived
perhaps from VFX, but not called VFX supporting the new portable 
standard. Thus he now has two products support until his clients
can port across to the new standard.

This is corner that the current standard(s) has/is painting people
into.

But I'm encouraged to see you aknowledge that the current standard
does not meet the goal of portability.

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

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

On 30/10/2015 11:17, Mark Wills wrote:
> On Thursday, 29 October 2015 16:13:15 UTC, Anton Ertl  wrote:
>> Well, actually, I do.  I want a standard in which one can easily write
>> programs which can be ported from one system to the next without
>> changing a single line of code.  If there are systems that have to
>> change to reach this goal, then they should change.
>>
>
> In that case, I urge the committee to step up to the plate, make the
> difficult, unpallatable, unpopular decisions, and give us a standard
> "in which one can easily write programs which can be ported from one
> system to the next without changing a single line of code."
>
> You seem to be advocating what I have been saying for a while.
>
> It's a different situation entirely for MPE though. For MPE, the
> only choice he would have in that circumstance, would be to
> support two systems in parallel; ANS94 and xxxx (too late for 2000x).
> His client with 1.2 million lines of code will not be happy if his
> code breaks over night because VFX is brought into line with a new
> standard; therefore MPE would have a create a new product, derived
> perhaps from VFX, but not called VFX supporting the new portable
> standard. Thus he now has two products support until his clients
> can port across to the new standard.
>
> This is corner that the current standard(s) has/is painting people
> into.
>
> But I'm encouraged to see you aknowledge that the current standard
> does not meet the goal of portability.
>

I disagree with that last statement. I have written a few large tools 
that run on at least 6 different ANS Forth systems. Once aware of 
ambiguous conditions and restrictions it is easy to avoid them, to do 
otherwise is sheer laziness on the part of the programmer.

About the only thing that stops programs being totally portable when 
using the same directory/file structure is the fact that there is no 
standard way to set a working directory or path, that varies with each 
system. But even then the source files themselves are portable. Anton 
has tried to sort that out but there has never been any agreement.

-- 
Gerry

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

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

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 30/10/2015 11:17, Mark Wills wrote:
>> But I'm encouraged to see you aknowledge that the current standard
>> does not meet the goal of portability.
>>
>
>I disagree with that last statement. I have written a few large tools 
>that run on at least 6 different ANS Forth systems. Once aware of 
>ambiguous conditions and restrictions it is easy to avoid them, to do 
>otherwise is sheer laziness on the part of the programmer.

Well, maybe all the people who have written non-portable Forth
programs are just lazy, but it seems that even though you consider it
easy, it's not easy enough for most programmers.  Anyway, I don't
think that the standards committee can just throw out a standard, and
then, when programmers fail to write programs that comply with the
standard, lean back and deplore the lazyness of the programmers;
instead, we should ask ourselves what we can do to make it easier and
more attractive for them to write standard programs.

A part of that is certainly cultural (making it a normal thing to
strive for portability rather than being satisfied that "programs of
any size" are non-portable), and educational (letting people know how
to write portable programs), but another part is changing the standard
in a way that it becomes easier to write portable programs.  E.g., not
having to jump through the hoop of writing CHARS here and 1 CHARS /
there when these operations are noops, and when you cannot really test
whether you have included all such uses where needed.

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

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

On 31/10/2015 15:25, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 30/10/2015 11:17, Mark Wills wrote:
>>> But I'm encouraged to see you aknowledge that the current standard
>>> does not meet the goal of portability.
>>>
>>
>> I disagree with that last statement. I have written a few large tools
>> that run on at least 6 different ANS Forth systems. Once aware of
>> ambiguous conditions and restrictions it is easy to avoid them, to do
>> otherwise is sheer laziness on the part of the programmer.
>
> Well, maybe all the people who have written non-portable Forth
> programs are just lazy, but it seems that even though you consider it
> easy,

Perhaps I should clarify that, I mean easy with full feature Forths 
running on a desktop - I don't use embedded systems. Clearly a program 
requiring use of wordlists won't run on a system that doesn't implement 
the optional Search-Order word set. Also as I wrote most of the 
Forth-94/2012 test suite I may be more familiar with portability pitfalls.

> it's not easy enough for most programmers.  Anyway, I don't
> think that the standards committee can just throw out a standard, and
> then, when programmers fail to write programs that comply with the
> standard, lean back and deplore the lazyness of the programmers;
> instead, we should ask ourselves what we can do to make it easier and
> more attractive for them to write standard programs.

Yes you've already done this with a few things e.g. replacing the 
Forth-95 locals, character constants & prefixes for numbers. This should 
be done for the real difficulties and not just simple things like CHARS 
& 2s complement arithmetic or academic language lawyer things that cause 
no problems in practice. We should start with a list of specific 
problems, Hugh has already listed a few things that I mostly agree with.


-- 
Gerry

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

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

On 30/10/2015 11:17, Mark Wills wrote:
> On Thursday, 29 October 2015 16:13:15 UTC, Anton Ertl  wrote:
>> Well, actually, I do.  I want a standard in which one can easily write
>> programs which can be ported from one system to the next without
>> changing a single line of code.  If there are systems that have to
>> change to reach this goal, then they should change.
>>
>
> In that case, I urge the committee to step up to the plate, make the
> difficult, unpallatable, unpopular decisions, and give us a standard
> "in which one can easily write programs which can be ported from one
> system to the next without changing a single line of code."
>
> You seem to be advocating what I have been saying for a while.
>
> It's a different situation entirely for MPE though. For MPE, the
> only choice he would have in that circumstance, would be to
> support two systems in parallel; ANS94 and xxxx (too late for 2000x).
> His client with 1.2 million lines of code will not be happy if his
> code breaks over night because VFX is brought into line with a new
> standard; therefore MPE would have a create a new product, derived
> perhaps from VFX, but not called VFX supporting the new portable
> standard. Thus he now has two products support until his clients
> can port across to the new standard.
>
> This is corner that the current standard(s) has/is painting people
> into.
>
> But I'm encouraged to see you aknowledge that the current standard
> does not meet the goal of portability.
>

I'm curious, not wishing to be rude. From previous posts you based your 
TMS9900 TurboForth system on the Forth 83 standard. Why did you choose 
an obsolete standard instead of ANS Forth? Was it the number of 
ambiguous conditions in ANS Forth that put you off. Have you actually 
tried to write a significant bit of software in ANS Forth i.e. is it 
experience or just opinion that makes you say it is difficult to write 
portable software?

-- 
Gerry

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

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

On Friday, 30 October 2015 20:51:11 UTC, Gerry  wrote:
> On 30/10/2015 11:17, Mark Wills wrote:
> > On Thursday, 29 October 2015 16:13:15 UTC, Anton Ertl  wrote:
> >> Well, actually, I do.  I want a standard in which one can easily write
> >> programs which can be ported from one system to the next without
> >> changing a single line of code.  If there are systems that have to
> >> change to reach this goal, then they should change.
> >>
> >
> > In that case, I urge the committee to step up to the plate, make the
> > difficult, unpallatable, unpopular decisions, and give us a standard
> > "in which one can easily write programs which can be ported from one
> > system to the next without changing a single line of code."
> >
> > You seem to be advocating what I have been saying for a while.
> >
> > It's a different situation entirely for MPE though. For MPE, the
> > only choice he would have in that circumstance, would be to
> > support two systems in parallel; ANS94 and xxxx (too late for 2000x).
> > His client with 1.2 million lines of code will not be happy if his
> > code breaks over night because VFX is brought into line with a new
> > standard; therefore MPE would have a create a new product, derived
> > perhaps from VFX, but not called VFX supporting the new portable
> > standard. Thus he now has two products support until his clients
> > can port across to the new standard.
> >
> > This is corner that the current standard(s) has/is painting people
> > into.
> >
> > But I'm encouraged to see you aknowledge that the current standard
> > does not meet the goal of portability.
> >
> 
> I'm curious, not wishing to be rude. From previous posts you based your 
> TMS9900 TurboForth system on the Forth 83 standard. Why did you choose 
> an obsolete standard instead of ANS Forth? Was it the number of 
> ambiguous conditions in ANS Forth that put you off. Have you actually 
> tried to write a significant bit of software in ANS Forth i.e. is it 
> experience or just opinion that makes you say it is difficult to write 
> portable software?
> 
> -- 
> Gerry

Hi Gerry. I went for Forth 83 because it's based around a 16-bit
universe, and the TMS9900 is 16 bit. Also, both the standard and
the CPU are from the same era, so it's a good fit. Previous Forth
incarnation on the same machine have been FIG based.

You are correct in intuiting that I have limited experience in
writing portable ANS code. I think my biggest effort in this area
would be the string stack library that I produced. I wrote it for
my system first, and then back ported it. If I remember correctly,
I did successfully test it in GForth, SwiftForth, and VFX. There
were relatively minor changes required to change it from Forth 83
to ANS94. Mainly, (again from memory) it was associated with reading
the terminal input buffer when compiling strings etc. It turned 
out to be not too difficult. I had already taken precautions when
writing the TurboForth version to use words like CELLS etc, so a 
lot of it "just worked". 

A description of the ANS library, complete with ANS cross references
etc, is available here: 

http://turboforth.net/downloads/docs/ANS_String_Lib.pdf

Then again, is that a "non-trivial" program/library? I would argue
that it's quite trivial. It becomes non-trivial when you are writing
code that writes code, that sort of thing. Hugh has some good examples
in his Novice package (poorly named, IMO. It's a neat package and
should be called something like Forth Toolkit) of words that write
custom words behind the scenes. This is where, in the main, one can
fall down a dark hole in ANS Forth. The argument would probably be
that for that kind of stuff, carnal knowledge would be required. But
it should be possible. We have tick, compile, postpone et al, but 
(for example) no standard way to create a blank, linked dictionary entry
with a name but no associated behaviour. This would allow colon
definitions (or other types of words) to be created on the fly at
run-time. As things stand, one would have to resort to EVALUATE for
that. Maybe that's okay.

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

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

Mark Wills <markwills1970@gmail.com> writes:
>We have tick, compile, postpone et al, but 
>(for example) no standard way to create a blank, linked dictionary entry
>with a name but no associated behaviour. This would allow colon
>definitions (or other types of words) to be created on the fly at
>run-time.

You can create a colon definition at run-time with : or :NONAME.  And
others with their respective defining words.  What is not easily
possible is to pass a string to a parsing word (such as all defining
words except :NONAME).  However, while that is not easy, it is
possible in standard Forth, see execute-parsing.fs in
<https://www.complang.tuwien.ac.at/forth/compat.zip>.

>As things stand, one would have to resort to EVALUATE for
>that. Maybe that's okay.

In many cases it has it's pitfalls, and it requires special effort to
avoid them (taken in evaluate-parsing.fs).

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

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

On 02/11/2015 09:39, Mark Wills wrote:
> On Friday, 30 October 2015 20:51:11 UTC, Gerry  wrote:
>> On 30/10/2015 11:17, Mark Wills wrote:

>> I'm curious, not wishing to be rude. From previous posts you based your
>> TMS9900 TurboForth system on the Forth 83 standard. Why did you choose
>> an obsolete standard instead of ANS Forth? Was it the number of
>> ambiguous conditions in ANS Forth that put you off. Have you actually
>> tried to write a significant bit of software in ANS Forth i.e. is it
>> experience or just opinion that makes you say it is difficult to write
>> portable software?
>>
>> --
>> Gerry
>
> Hi Gerry. I went for Forth 83 because it's based around a 16-bit
> universe, and the TMS9900 is 16 bit. Also, both the standard and
> the CPU are from the same era, so it's a good fit. Previous Forth
> incarnation on the same machine have been FIG based.

It's good that you are promoting Forth and I hope that some users are 
inspired to use Forth more widely and not be put off by the fact that 
ANS Forth is different.

>
> You are correct in intuiting that I have limited experience in
> writing portable ANS code. I think my biggest effort in this area
> would be the string stack library that I produced. I wrote it for
> my system first, and then back ported it. If I remember correctly,
> I did successfully test it in GForth, SwiftForth, and VFX. There
> were relatively minor changes required to change it from Forth 83
> to ANS94. Mainly, (again from memory) it was associated with reading
> the terminal input buffer when compiling strings etc. It turned
> out to be not too difficult. I had already taken precautions when
> writing the TurboForth version to use words like CELLS etc, so a
> lot of it "just worked".
>
> A description of the ANS library, complete with ANS cross references
> etc, is available here:
>
> http://turboforth.net/downloads/docs/ANS_String_Lib.pdf

Have you publicised this more widely, I haven't seen this link before 
but may have missed it. If you're happy/proud of it why not FLAG it up 
on MPE's web-site. I'll have a look at it in slower time.

>
> Then again, is that a "non-trivial" program/library? I would argue
> that it's quite trivial.

Who can say, 'trivial' depends on knowledge and experience. It doesn't 
sound as if the ANS standard gave you much trouble.

> It becomes non-trivial when you are writing
> code that writes code, that sort of thing. Hugh has some good examples
> in his Novice package (poorly named, IMO. It's a neat package and
> should be called something like Forth Toolkit)

I remember telling Hugh that it was a bad name some years ago but it 
fell on deaf ears.

> of words that write
> custom words behind the scenes. This is where, in the main, one can
> fall down a dark hole in ANS Forth. The argument would probably be
> that for that kind of stuff, carnal knowledge would be required. But
> it should be possible. We have tick, compile, postpone et al, but
> (for example) no standard way to create a blank, linked dictionary entry
> with a name but no associated behaviour. This would allow colon
> definitions (or other types of words) to be created on the fly at
> run-time. As things stand, one would have to resort to EVALUATE for
> that. Maybe that's okay.
>

I'm not sure what you mean by that. If you mean you want an equivalent 
of, say, CREATE such as CREATE$ (caddr u -- ) that creates a word with 
the name (caddr u) then that has been a recurring complaint from people, 
including me, for many years. The 'standard' way is to use Anton Ertl's 
EXECUTE-PARSING https://www.complang.tuwien.ac.at/forth/compat.zip which 
does use EVALUATE. e.g.

: create$ ['] create execute-parsing ;

Then you can associate any behaviour you want using DOES>

Similarly for any other defining word that parses, : DEFER etc.

-- 
Gerry

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

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

On Monday, 2 November 2015 12:09:00 UTC, Gerry  wrote:
> On 02/11/2015 09:39, Mark Wills wrote:
> > On Friday, 30 October 2015 20:51:11 UTC, Gerry  wrote:
> >> On 30/10/2015 11:17, Mark Wills wrote:
> 
> >> I'm curious, not wishing to be rude. From previous posts you based your
> >> TMS9900 TurboForth system on the Forth 83 standard. Why did you choose
> >> an obsolete standard instead of ANS Forth? Was it the number of
> >> ambiguous conditions in ANS Forth that put you off. Have you actually
> >> tried to write a significant bit of software in ANS Forth i.e. is it
> >> experience or just opinion that makes you say it is difficult to write
> >> portable software?
> >>
> >> --
> >> Gerry
> >
> > Hi Gerry. I went for Forth 83 because it's based around a 16-bit
> > universe, and the TMS9900 is 16 bit. Also, both the standard and
> > the CPU are from the same era, so it's a good fit. Previous Forth
> > incarnation on the same machine have been FIG based.
> 
> It's good that you are promoting Forth and I hope that some users are 
> inspired to use Forth more widely and not be put off by the fact that 
> ANS Forth is different.
> 
> >
> > You are correct in intuiting that I have limited experience in
> > writing portable ANS code. I think my biggest effort in this area
> > would be the string stack library that I produced. I wrote it for
> > my system first, and then back ported it. If I remember correctly,
> > I did successfully test it in GForth, SwiftForth, and VFX. There
> > were relatively minor changes required to change it from Forth 83
> > to ANS94. Mainly, (again from memory) it was associated with reading
> > the terminal input buffer when compiling strings etc. It turned
> > out to be not too difficult. I had already taken precautions when
> > writing the TurboForth version to use words like CELLS etc, so a
> > lot of it "just worked".
> >
> > A description of the ANS library, complete with ANS cross references
> > etc, is available here:
> >
> > http://turboforth.net/downloads/docs/ANS_String_Lib.pdf
> 
> Have you publicised this more widely, I haven't seen this link before 
> but may have missed it. If you're happy/proud of it why not FLAG it up 
> on MPE's web-site. I'll have a look at it in slower time.
> 

Yes, I'll send it Stephen for consideration. 

> >
> > Then again, is that a "non-trivial" program/library? I would argue
> > that it's quite trivial.
> 
> Who can say, 'trivial' depends on knowledge and experience. It doesn't 
> sound as if the ANS standard gave you much trouble.

In the main, it doesn't. It just comes down to flicking through the 
standard to find the word I'm looking for.


> 
> > It becomes non-trivial when you are writing
> > code that writes code, that sort of thing. Hugh has some good examples
> > in his Novice package (poorly named, IMO. It's a neat package and
> > should be called something like Forth Toolkit)
> 
> I remember telling Hugh that it was a bad name some years ago but it 
> fell on deaf ears.
> 
> > of words that write
> > custom words behind the scenes. This is where, in the main, one can
> > fall down a dark hole in ANS Forth. The argument would probably be
> > that for that kind of stuff, carnal knowledge would be required. But
> > it should be possible. We have tick, compile, postpone et al, but
> > (for example) no standard way to create a blank, linked dictionary entry
> > with a name but no associated behaviour. This would allow colon
> > definitions (or other types of words) to be created on the fly at
> > run-time. As things stand, one would have to resort to EVALUATE for
> > that. Maybe that's okay.
> >
> 
> I'm not sure what you mean by that. If you mean you want an equivalent 
> of, say, CREATE such as CREATE$ (caddr u -- ) that creates a word with 
> the name (caddr u) then that has been a recurring complaint from people, 
> including me, for many years. The 'standard' way is to use Anton Ertl's 
> EXECUTE-PARSING https://www.complang.tuwien.ac.at/forth/compat.zip which 
> does use EVALUATE. e.g.
> 
> : create$ ['] create execute-parsing ;
> 
> Then you can associate any behaviour you want using DOES>
> 
> Similarly for any other defining word that parses, : DEFER etc.
> 
> -- 
> Gerry

Yes, pretty much. For example, on my system I have HEADER, that creates
a new, linked dictionary entry, but no behaviour, so you can make it
a constant, a variable, a colon-def, whatever, by comma-ing in the
appropriate XTs.

So I can have (trivial example):

: make-word ( c-addr u -- ) 
  header,
  compile docol
  compile lit 10 , 
  compile lit 20 , 
  compile + 
  compile exit
;

s" fred" make-word

and you end up with a colon-def called fred which adds 10 and 20.

This functionality is nice with dealing with arrays and structures.

For example, you might have a word that creates an array, called make-
array, that also creates reader and writer words for you:

24 80 2 make-array screen

creates a 2d array, 24x80 called screen. But also creates:

screen@ ( x y -- n )
screen! ( x y n -- )

for you automagically. You could have the same thing for serial ports
and the like.

s" 9600 8 n 1" make-serial outstation

s" echo: hello?" >outstation
outstation> type

This would be very nice and significantly aid in cross-compilation etc.

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

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

> I'm not sure what you mean by that. If you mean you want an equivalent 
> of, say, CREATE such as CREATE$ (caddr u -- ) that creates a word with 
> the name (caddr u) then that has been a recurring complaint from people, 
> including me, for many years. The 'standard' way is to use Anton Ertl's 
> EXECUTE-PARSING https://www.complang.tuwien.ac.at/forth/compat.zip which 
> does use EVALUATE. e.g.
> 
> : create$ ['] create execute-parsing ;
> 
> Then you can associate any behaviour you want using DOES>
> 
> Similarly for any other defining word that parses, : DEFER etc.
> 
> -- 
> Gerry

Here is the begining of my "standard library":

s" :" $def bl parse $def ;
: i:       bl parse $idef ;
: wordlist bl parse $wordlist ;
: build    bl parse $build ;
: ibuild   bl parse $ibuild ;
: data     bl parse $data ;
: const    bl parse $const ;
: defer    bl parse $defer ;
: is       bl parse $is ;
: constant bl parse $constant ;

i: &&&  '&' rem ;     \ &&& ... & block (embedded) comment
i: comment            \ comment <char> ... <char> block (embedded) comment
  bl parse drop c@ rem ;

1 constant C \ one char
2 constant H \ half a cell
4 constant W \ one cell
8 constant D \ double cell

: allot   here +! ;     \ size --
: var     data allot ;  \ "name" size --

:  variable  W var ;
: cvariable  C var ;
: hvariable  H var ;

\ Usage: variables a b c d ;
: variables
  begin
    bl parse \ adr len
    dup 1 = if
      over c@ ';' = if 2drop exit then
    then
    $data W allot
  again ;

The kernel has only $ words ($def $idef $wordlist $build $ibuild $data
$const $defer $is $constant). They all expect an "adr len" string as a 
parameter. There is no parsing word in the kernel.

It is not seen here, but I also have $header - doing exactly this: 
create a new empty dictionary header (based on adr len string too).

You can obeserve the first line, which defines the ":" :) 
Without it you can imagine how the rest of the lines will look like.

For a while I had this line being: 
s" def" $def bl parse $def ;
But I switched to more "traditional ":" ...

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

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

Mark Wills <markwills1970@gmail.com> writes:
>Then again, is that a "non-trivial" program/library? I would argue
>that it's quite trivial. It becomes non-trivial when you are writing
>code that writes code, that sort of thing.

I like to do that and find that Forth-94 is quite well suited to do
that.  As an example, look at my parser generator Gray:
<https://www.complang.tuwien.ac.at/forth/Gray5.zip>.

>Hugh has some good examples
>in his Novice package (poorly named, IMO. It's a neat package and
>should be called something like Forth Toolkit) of words that write
>custom words behind the scenes. This is where, in the main, one can
>fall down a dark hole in ANS Forth.

The standard certainly could be tightened there.  But I doubt that
Hugh Aguilar would be satisfied if, say, the Gforth approach or the
VFX approach to dealing with ' IF was standardized.

OTOH, if you use Gforth, you will notice right away that ' IF is not
doing what you want (that's why we made it produce an error), and can
work around the problem.  E.g., if you want the xt of a word that,
when EXECUTEd performs the compilation semantics of IF, you can do
that with:

: comp-if postpone if ;

and then use ' COMP-IF.  Or, with quotations, you could write

[: postpone if ;]

>The argument would probably be
>that for that kind of stuff, carnal knowledge would be required.

That's certainly a frequent commercial vendor argument.

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

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

On 02/11/2015 09:39, Mark Wills wrote:
> A description of the ANS library, complete with ANS cross references
> etc, is available here:
>
> http://turboforth.net/downloads/docs/ANS_String_Lib.pdf
>

Hi Mark

As promised in aa previous reply I had a look at your string library and 
emailed you some bugs & comments. I know some people don't even look at 
emails sent to the address on their posts. So did you receive my 
comments, if not send me an email address (mine does work) &  I'll re-send.

-- 
Gerry

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

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

Hi Gerry

Yes I did get your email thanks. I just haven't had a chance to look yet. Been dealing with a bereavement in the family. I'll get to it in the next couple of weeks! 

Thanks

Mark

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

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

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

csiph-web