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

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

On 10/24/15 10:34 PM, Raimond Dragomir wrote:
>> 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).

In fact, Forth94 (now 20 years old) proved very successful in enabling 
reasonable transitions. FORTH, Inc. is often called upon to work on code 
written for other Forths, and only a few years after Forth94 was passed 
and widely adopted it became far easier to do so. The simple task of 
documenting dependencies is extremely powerful.

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

We do not see that. FORTH, Inc. continues to be busy selling systems and 
supporting many customers, but that doesn't seem to get much publicity.

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]

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

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>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).

If you don't care for the things that have been standardized, because
you know the best roof material for the bike shed, you are a typical
example of the reasons why we have a weak standard.

>I said my forth is probably 90% standard. It should be usable by any
>forther right away, even to the most seasoned ones...

By using names of standard words with non-standard meaning, you make
it hard for people to understand programs written for your dialect,
because the words do different things from what they expect.

And contrary to what Elizabeth Rather writes, even if you only use it
for yourself, it does matter, because you write here (and maybe
elsewhere about it).

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

Many have that courage.  The only problem is that they all disagree on
what 90% they want to keep, and what it takes to look like a more
modern language.

And then there is the all-important bike shed issue.  While Gforth has
had the name FIND-NAME for the word that you call SEARCH since 1996,
that's apparently not modern enough for you, so you use the (more
modern?) name SEARCH for the same word, even though that name has been
standardized to mean something else.

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

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

On 10/24/15 11:16 PM, Anton Ertl wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> 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).
>
> If you don't care for the things that have been standardized, because
> you know the best roof material for the bike shed, you are a typical
> example of the reasons why we have a weak standard.
>
>> I said my forth is probably 90% standard. It should be usable by any
>> forther right away, even to the most seasoned ones...
>
> By using names of standard words with non-standard meaning, you make
> it hard for people to understand programs written for your dialect,
> because the words do different things from what they expect.
>
> And contrary to what Elizabeth Rather writes, even if you only use it
> for yourself, it does matter, because you write here (and maybe
> elsewhere about it).

Anton, I do agree with you on this. In addition to the other factors I 
listed, communication within the Forth community depends on our using 
the same words for the same things.

>> 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.
>
> Many have that courage.  The only problem is that they all disagree on
> what 90% they want to keep, and what it takes to look like a more
> modern language.
>
> And then there is the all-important bike shed issue.  While Gforth has
> had the name FIND-NAME for the word that you call SEARCH since 1996,
> that's apparently not modern enough for you, so you use the (more
> modern?) name SEARCH for the same word, even though that name has been
> standardized to mean something else.
>
> - anton
>


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

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

On Sunday, October 25, 2015 at 2:36:19 AM UTC-7, Anton Ertl wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >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).
> 
> If you don't care for the things that have been standardized, because
> you know the best roof material for the bike shed, you are a typical
> example of the reasons why we have a weak standard.

Raimond Dragomir is to blame for ANS-Forth being a weak standard??? Is he also to blame for the Vietnam War and for the epidemic of obesity in America? Lets blame him for everything! Actually, we all know who is to blame for ANS-Forth --- Anton Ertl can't say it though, because if he does then she will remove him from his job as Forth-200x chair-person and appoint somebody who is more loyal.

I think that Anton Ertl conflates the concept of having a standard for Forth, with ANS-Forth --- he assumes that ANS-Forth is the only possible standard for Forth and that anybody who criticizes ANS-Forth is criticizing the concept of there being a standard. 

Having a standard for Forth is actually a good idea. It has to be designed by programmers though, rather than by a sales-person --- it has to make sense --- start any time!

It is possible to have two Forth standards in effect at the same time. There can be ANS-Forth, and there can be a new standard that makes sense. There will be a transition period during which the compiler-writers will have to support both standards. Over time however, ANS-Forth will fade away because nobody is writing new code in ANS-Forth --- the ANS-Forth version of each compiler will only be used to support legacy code --- over time however, all the legacy code that has any value will be ported over to the new standard and ANS-Forth will become obsolete. 

This is similar to how MS-DOS became obsolete --- for a while it continued to be supported so people could keep their legacy programs going, although nobody was writing new code for MS-DOS --- now MS-DOS is just a retro OS no more useful than Mark Wills' TI99/4A, but not as much fun.

P.S. I have no idea what your bike-shed analogy was supposed to mean.

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

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

Raimond Dragomir wrote:

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

Actually, you want a weaker standard, where you can assign new meanings to 
already standardized words; you are part of the problem, not the solution.  
We have other people who used long-common practice words with different 
meanings (e.g. the { notation for locals clashed with the { notation for 
multi-line comments), and forced us to choose a different naem for 
standardization.  If you don't like clashing on the return stack, use 
separate stacks in your implementation; that's permitted.  Others do like to 
have a small number of stacks due to the limited number of registers on 
their primary target (e.g x86).

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

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

On Sunday, 25 October 2015 08:34:09 UTC, Raimond Dragomir  wrote:
> 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.

I've been saying that for years. 200x should have been a clean-sheet
standard, with (obviously) similarities to ANS94, but without so much
"looking back over the shoulder" wrt to compatibility with the old
standard. If something in ANS proved to be a crap idea, then toss it
and do something else. Breaks "legacy" code? Tough. Stick with the
old standard (it doesn't vanish into thin air when a new standard
comes out) or re-write your application.

However, this isn't really how standards seem to work. Can't really
blame the current crop of Forth standards keepers. That 200x is 
incrementally related to its predecessor is no different to any 
other standard in computing circles, as far as I can tell.

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

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

Mark Wills <markwills1970@gmail.com> writes:
> I've been saying that for years. 200x should have been a clean-sheet
> standard, with (obviously) similarities to ANS94,

That sounds really ambitious.  Certainly there should be working
implementations before attempting standardization.  And what is out
there, that's in the spirit of Forth at all, but has radical enough
improvements from ANS94 to make it worth breaking compatibility?  Have
you got some concrete ideas or implementations?

Colorforth is radically different, but I don't think it's what the rest
of the Forth world is looking for.  Languages like Oforth and 8th are
cool and different but I think they're not really Forth in the
historical sense of minimizing hardware requirements, etc.

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

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

On 10/26/2015 11:07, Paul Rubin wrote:

> Languages like Oforth and 8th are
> cool and different but I think they're not really Forth in the
> historical sense of minimizing hardware requirements, etc.

At least we're cool :)

The real departing points for 8th vs standard Forth is the lack of 
CREATE ... DOES> and the (purposeful) inability to access arbitrary 
memory locations.  The rest is more or less syntactic niceties.

Size is less the issue; I would think Win32Forth is considered "really 
Forth", but it's pretty big and not close to the hardware.

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

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

The only thing wrong with ANS94 is its ambiguity and open-ness. It would actually benefit from being more prescriptive and more specific. More 'shall' and less 'may'. That's all it ever needed. 

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

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

On 10/25/15 11:07 PM, Paul Rubin wrote:
> Mark Wills <markwills1970@gmail.com> writes:
>> I've been saying that for years. 200x should have been a clean-sheet
>> standard, with (obviously) similarities to ANS94,
>
> That sounds really ambitious.  Certainly there should be working
> implementations before attempting standardization.  And what is out
> there, that's in the spirit of Forth at all, but has radical enough
> improvements from ANS94 to make it worth breaking compatibility?  Have
> you got some concrete ideas or implementations?
>
> Colorforth is radically different, but I don't think it's what the rest
> of the Forth world is looking for.  Languages like Oforth and 8th are
> cool and different but I think they're not really Forth in the
> historical sense of minimizing hardware requirements, etc.
>

Exactly. If you want a clean slate, go ahead, just give it a different 
name. If this fresh concept is really great, folks will flock to it for 
new programs, but legacy code can continue to evolve with incremental 
Forth standards.

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]

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

On Monday, October 26, 2015 at 12:22:53 PM UTC-7, Elizabeth D. Rather wrote:
> On 10/25/15 11:07 PM, Paul Rubin wrote:
> > Mark Wills <markwills1970@gmail.com> writes:
> >> I've been saying that for years. 200x should have been a clean-sheet
> >> standard, with (obviously) similarities to ANS94,
> >
> > That sounds really ambitious.  Certainly there should be working
> > implementations before attempting standardization.  And what is out
> > there, that's in the spirit of Forth at all, but has radical enough
> > improvements from ANS94 to make it worth breaking compatibility?  Have
> > you got some concrete ideas or implementations?
> >
> > Colorforth is radically different, but I don't think it's what the rest
> > of the Forth world is looking for.  Languages like Oforth and 8th are
> > cool and different but I think they're not really Forth in the
> > historical sense of minimizing hardware requirements, etc.
> >
> 
> Exactly. If you want a clean slate, go ahead, just give it a different 
> name. If this fresh concept is really great, folks will flock to it for 
> new programs, but legacy code can continue to evolve with incremental 
> Forth standards.
> 
> Cheers,
> Elizabeth

You don't own the name "Forth" --- you have no legal standing for denying anybody the right to use the name.

You tried to prevent anybody from using the name Forth or using any language derived from Forth, but Charles Moore refused to back you up on this and he left Forth Inc. because of this argument --- so you are left with no legal standing for denying anybody the right to use the name Forth --- only Charles Moore can do this, and he isn't doing it.

BTW: Paul Rubin says: "Certainly there should be working implementations before attempting standardization." Yet, your muddled "standard" went through ANSI and became ANS-Forth in 1994 without any reference compiler having ever been written --- the first ANS-Forth system available was SwiftForth in 1997 that cost over $400 and was too bug-ridden to be usable --- the result is that ANS-Forth is not self-consistent, is full of ambiguities, and contains blatant bugs.

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

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

Mark Wills <markwills1970@gmail.com> writes:
>I've been saying that for years. 200x should have been a clean-sheet
>standard, with (obviously) similarities to ANS94, but without so much
>"looking back over the shoulder" wrt to compatibility with the old
>standard. If something in ANS proved to be a crap idea, then toss it
>and do something else. Breaks "legacy" code? Tough. Stick with the
>old standard (it doesn't vanish into thin air when a new standard
>comes out) or re-write your application.

We have had such a standard: Forth-83.  It's best known for bing
incompatible with Forth-79 on several issues, in particular on what
comparison words return for "true" (-1 instead of Forth-79's 1), the
meaning of NOT (bitwise complement instead of Forth-79's equivalence
to 0=), and the meaning of PICK and ROLL (0 PICK is DUP instead of, in
Forth-79, 1 PICK).

Maybe the Forth-79 choices were crap ideas, but to me these changes
appear minor and are not worth the incompatibility they caused.  And
even if we cannot live with the old way, the way to go is to have new
names for the new meanings.  This allows a gradual transition instead
of requiring a large effort before one gets any benefit from the new
standard; many people will shy away from taking such a big step.

What are the issues that you consider crap in Forth-94/-2012?

What are the issues that you think require abandoning backwards
compatibility?

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

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

On Monday, 26 October 2015 11:19:48 UTC, Anton Ertl  wrote:
> What are the issues that you consider crap in Forth-94/-2012?
> 
> What are the issues that you think require abandoning backwards
> compatibility?
> 

See my post above. Removing ambiguity - it may not require the addition
or removal of words at all. Just tighter language. There's too much
may and not enough shall. When there's too much may you end up 
standardising non-standard behaviour, since there's wriggle room to 
claim that a particular interpretation of the text is within the (wide)
confines of the standard.

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

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

Mark Wills wrote:

> On Monday, 26 October 2015 11:19:48 UTC, Anton Ertl  wrote:
>> What are the issues that you consider crap in Forth-94/-2012?
>> 
>> What are the issues that you think require abandoning backwards
>> compatibility?
>> 
> 
> See my post above. Removing ambiguity - it may not require the addition
> or removal of words at all. Just tighter language. There's too much
> may and not enough shall. When there's too much may you end up
> standardising non-standard behaviour, since there's wriggle room to
> claim that a particular interpretation of the text is within the (wide)
> confines of the standard.

One reason Forth-94 is ambiguous is the diversity of Forth systems back 
then.  Forth-83 was non-ambiguous, and specified even the implementation 
strategy (threaded code), and the cell size (16 bits).  This was too 
limited, and people diverted from the standard.

A standard which is too tight is not useful, because no system implementer 
is going to adhere it.  A standard which is too permissive is not useful, 
because no program will be written for it (in the sense of "runs on every 
standard system", not in the sense of "standard program with environmental 
restrictions, runs on one system, fails on every other").

The last meeting had two RfDs/CfVs on the table to decide tightening up the 
standard.  In the case of two's complement, the decision was apparently 
easy: Nobody uses anything else.  With the 1 CHARS = 1, three people needed 
"more time".

The "if you don't want it, use the old standard" is not so easy for people 
who use commercial systems.  They want maintenance, and the supplier want to 
support the latest standard, because some customrs want that - but not all 
of them.  In the batch compiling world, you often can select which standard 
the compiler uses, like -std=<standard name> in GCC.

In Forth, you sometimes see that in transition phases, where you have to 
load a file to get compatible to the new standard (or load files for 
extension wordsets), but not in the same highly configurable manner as with 
GCC.

So we want to be compatible with old code; usually not just old standard 
code, but also make it possible for the vendors to be compatible with their 
own extensions.  The more problems a standard causes while implementing and 
deployment, the less it will be adhered.

We also don't specify things which nobody yet implemented; the C/C++ people 
do, and then you have a new standard, but the compilers implement it only 
partly.  That's crazy.

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

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

Mark Wills <markwills1970@gmail.com> writes:
>See my post above. Removing ambiguity - it may not require the addition
>or removal of words at all. Just tighter language. There's too much
>may and not enough shall.

RfDs welcome.  Note that some ideas for removing ambiguity that some
people have advocated (in particular, requiring a separate
control-flow stack) are contrary to common practice and are therefore
unlikely to be accepted.

And somehow it seems to be much harder to remove explicit ambiguity
than to add new words, even if deciding for one way on this ambiguity
is much more common practice than the new words.

As an example, we decided to standardize a separate FP stack back in
2008, yet in the last two meetings a committee member brings up again
and again that on some particular CPU one can gain some efficiency
(without providing numbers) by having a system with (now) an
environmental restriction of having a shared stack with single-cell FP
values, *and* writing a program that even in Forth-94 has an
environmental dependency on a shared stack with single-cell FP values.

Interestingly, when I compare programs without environmental
dependencies, I expect that a Forth-2012 program (that relies on the
separate FP stack) will be similarly fast on that particular CPU (and
easier to write) compared to a Forth-94 program, while the Forth-2012
program runs faster on most other CPUs, and I have numbers for that:

With gforth-fast on a Core i7-4790K (4.4GHz):

                                Forth-2012  Forth-94
500x500 mm - normal algorithm     0.570s     0.727s
500x500 mm - transposed B matrix  0.550s     0.686s
500x500 mm - Robert's algorithm   0.547s     0.684s

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

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

On Tue, 27 Oct 2015 17:09:41 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>As an example, we decided to standardize a separate FP stack back in
>2008, yet in the last two meetings a committee member brings up again
>and again that on some particular CPU one can gain some efficiency
>(without providing numbers) by having a system with (now) an
>environmental restriction of having a shared stack with single-cell FP
>values

That would be me. I'll attempt to provide some numbers for you in my
"ample spare time".

Every time there's a substantial change in the standard we have to be
careful that what looks like good practice will remain so in the
future. 

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.

So we see that assumptions made in one decade may be wrong in another.
In an embedded system, code size, data size and performance trump
anything that a standard says.

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]

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

stephen@mpeforth.com (Stephen Pelc) writes:
>On Tue, 27 Oct 2015 17:09:41 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>That would be me. I'll attempt to provide some numbers for you in my
>"ample spare time".

Ideally that would be numbers for a Forth-94 program (where the
program has to work around the fact that it does not know whether the
FP stack is separate or shared), a Forth-2012 program (which can rely
on a separate FP stack), and a program with an environmental
dependency on a shared stack and single-cell FP values.

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

If you want efficient FP, you won't be using the Cortex-M4F.  Every
CPU where FP efficiency plays a role (including higher-performance
ARMs), uses a separate FP register file; that was true in the CDC 6600
in 1965, and it's true now, 50 years later, and the reason for that is
physics.  And implementing a shared stack for such CPUs is
inefficient.

> As Klaus showed at EuroForth 2015, 32 bit FP has a point.

It's good enough for some applications, but many others need more.
CPU manufacturers don't make 64-bit FPUs because they don't know what
to do with the transistors, but because they are needed by
applications.  And they are longer in the FP business than Klaus, and
know more about it.

>It will become more common in the future.

Any evidence to support that claim?

Counter-evidence: When I google for "ARM Floating Point", 

> A shared data stack is looking
>like a good compromise.

Let's see:

1) On one hand, everybody who is interested in high-performance FP is
working on CPUs where a separate stack provides a good performance
advantage (as well as making programming easier).

2) And then there are the people who are not really interested in
high-performance FP, so they buy a Cortex-M4F; yet they want everybody
else to have slower FP (and, in many cases, insufficiently accurate
FP) in order to have faster FP themselves.

Giving in to the second group of people really looks like a good
compromise.  Not!

>So we see that assumptions made in one decade may be wrong in another.

But in this case they are not.

>In an embedded system, code size, data size and performance trump
>anything that a standard says.

In that case, why care about what the standard says?  Just implement
FP for the Cortex-M4F to have an environmental restriction of a shared
stack and single-cell FP values, and write programs with an
environmental dependency on a shared stack and single-cell FP values,
and be happy.  Or you could go the traditional MPE way and provide
several floating-point packages, a standard one and one that is fast
for the Cortex-M4F.

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

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

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.

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

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

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

No, these embedded device line has a selection of devices with different 
capabilities and price points.  Some of them become obsolete over time when 
there are not enough customers to buy them, e.g. because the feature 
difference is not big enough to choose one over the other.

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

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

Bernd Paysan <bernd.paysan@gmx.de> writes:
> No, these embedded device line has a selection of devices with
> different capabilities and price points.  Some of them become obsolete
> over time when there are not enough customers to buy them,
> e.g. because the feature difference is not big enough to choose one
> over the other.

The old devices stay in the catalog and people buy them for use in
existing designs, and maybe they get into new high-volume designs that
are very cost sensitive.  But otherwise, do designers of new systems
still select the M0 instead of the M0+, or for that matter the M3 or M4
instead of the M4F?  TI seems to have brought ARM into its low-power
line, for example, with the MSP432 that uses an M4F core.  I was
surprised it wasn't an M0+ (this is the model in the MSP432 Launchpad;
I'm not sure if all the MSP432's are like that).  But I guess they
figured that the M0+'s power and cost benefits weren't enough to give up
the M4F's added capabilities.

The M7 is supposed to be faster and more power efficient than the M4F
(besides having double precision) so unless it costs a lot more I'd
expect it to gain some widespread use.  It is still very new though.

I certainly remember being disappointed to find out that the M4F has
only single precision.

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

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

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

csiph-web