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

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

Essential properties of current standard Forth

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

Contents

  Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-15 14:19 +0000
    Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-15 17:58 -0700
      Re: Essential properties of current standard Forth tabcomputing@gmail.com - 2016-09-24 18:48 -0700
        Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-24 21:47 -0700
          Re: Essential properties of current standard Forth tabcomputing@gmail.com - 2016-09-25 08:11 -0700
            Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-25 20:14 -0700
              Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 11:12 +0200
                Re: Essential properties of current standard Forth Alex <alex@rivadpm.com> - 2016-09-26 12:16 +0100
                  Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 14:30 +0200
                    Re: Essential properties of current standard Forth Coos Haak <htrofhc@gmail.com> - 2016-09-26 15:10 +0200
                      Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 16:07 +0200
                  Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 13:43 +0000
                    Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 16:36 +0200
          Re: Essential properties of current standard Forth Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-09-25 15:18 -0400
    Re: Essential properties of current standard Forth anotherreepca@gmail.com - 2016-09-18 09:01 -0700
      Re: Essential properties of current standard Forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-18 11:35 -0500
        Re: Essential properties of current standard Forth minforth@arcor.de - 2016-09-19 03:21 -0700
          Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-19 09:49 -0500
            Re: Essential properties of current standard Forth minforth@arcor.de - 2016-09-19 12:38 -0700
              Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-20 11:23 -0500
                Re: Essential properties of current standard Forth lawrencedo99@gmail.com - 2016-09-20 12:55 -0700
                  Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-21 02:24 +0200
                Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-20 14:52 -0700
        Re: Essential properties of current standard Forth JUERGEN <epldfpga@aol.com> - 2016-09-19 10:12 -0700
          Re: Essential properties of current standard Forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-19 12:40 -0500
      Re: Essential properties of current standard Forth stephen@mpeforth.com (Stephen Pelc) - 2016-09-21 10:09 +0000
    Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-19 13:29 +0200
      Re: Essential properties of current standard Forth foxaudioresearch@gmail.com - 2016-09-19 07:16 -0700
      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-19 17:10 +0000
    Re: Essential properties of current standard Forth humptydumpty <ouatubi@gmail.com> - 2016-09-20 22:43 -0700
      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-21 12:39 +0000
        Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-22 11:40 -0700
          Re: Essential properties of current standard Forth humptydumpty <ouatubi@gmail.com> - 2016-09-23 09:28 -0700
        Re: Essential properties of current standard Forth humptydumpty <ouatubi@gmail.com> - 2016-09-23 09:19 -0700
    Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-23 20:11 -0700
      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-24 10:55 +0000
        Re: Essential properties of current standard Forth Matthias Trute <matthias.trute@gmail.com> - 2016-09-24 11:14 -0700
          Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-25 03:01 -0500
            Re: Essential properties of current standard Forth Matthias Trute <matthias.trute@gmail.com> - 2016-09-25 02:21 -0700
              Re: Essential properties of current standard Forth lawrencedo99@gmail.com - 2016-09-25 14:01 -0700
              Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-25 15:04 -0700
                Re: Essential properties of current standard Forth lawrencedo99@gmail.com - 2016-09-25 17:39 -0700
                  Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-25 17:56 -0700
                Re: Essential properties of current standard Forth Mikael Nordman <oh2aun@gmail.com> - 2016-09-25 20:34 -0700
                  Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-25 22:37 -0700
                Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 02:34 -0500
                  Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 14:04 +0000
                    Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 10:40 -0500
                      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-28 06:43 +0000
                        Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-28 04:48 -0500
            Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 14:58 +0000
              Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 11:02 -0500
                Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 23:28 +0000
                  Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 03:49 -0500
                Re: Essential properties of current standard Forth Alex <alex@rivadpm.com> - 2016-09-27 11:43 +0100
          Standardization (was: Essential properties of current standard Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 16:01 +0000
            Re: Standardization (was: Essential properties of current standard Forth) stephen@mpeforth.com (Stephen Pelc) - 2016-09-26 20:06 +0000
              Re: Standardization (was: Essential properties of current standard Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 14:49 +0000
                Re: Standardization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 11:20 -0500
                Re: Standardization (was: Essential properties of current standard Forth) stephen@mpeforth.com (Stephen Pelc) - 2016-09-28 12:07 +0000
                  Re: Standardization (was: Essential properties of current standard Forth) Bernd Paysan <bernd@net2o.de> - 2016-09-29 02:07 +0000
                    Re: Standardization (was: Essential properties of current standard Forth) hughaguilar96@gmail.com - 2016-09-28 19:40 -0700
                      Re: Standardization (was: Essential properties of current standard Forth) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-09-29 15:22 -0700
                    Re: Standardization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-29 04:12 -0500
                    Re: Standardization (was: Essential properties of current standard Forth) stephen@mpeforth.com (Stephen Pelc) - 2016-09-29 10:15 +0000
                  Re: Standardization (was: Essential properties of current standard Forth) Matthias Trute <matthias.trute@gmail.com> - 2016-09-29 10:38 -0700
        Re: Essential properties of current standard Forth trans <transfire@gmail.com> - 2016-09-26 18:04 -0700
          Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 13:37 +0000
    Re: Essential properties of current standard Forth jim.brakefield@ieee.org - 2016-09-28 13:54 -0700

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

#51297

Matthias Trute <matthias.trute@gmail.com> writes:
> Forth became an unknown hidden language, that's a tragedy. Erlang is a 
> hidden language too, but a well known one, considered for new projects.

Forth historically solved a problem (interactive, reasonable performance
development environment on low-resource machines) that's less important
now than it used to be, and most programmers these days don't want to
deal with the tradeoffs Forth made to solve that problem, unless they
are dealing with the same problem.

The Arduino really does seem like a natural Forth target, though.  It
would be great if Amforth had more uptake.  Do you think of encouraging
vendors of Atmel boards to ship with Amforth already installed?  Or
maybe just flash a pile of Atmega328 parts and sell them to people?

> I agree that recognizers are not that fine tuned yet. That's why I
> didn't start a CfV.

Recognizers seem like a good idea, even if there are issues still to
work out.

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

#51299

On Monday, September 26, 2016 at 11:04:43 AM UTC+13, Paul Rubin wrote:
> The Arduino really does seem like a natural Forth target, though.

I don’t think the Arduino can self-host any kind of development environment; you usually cross-compile from some other machine. Something as modest as a Raspberry π will do.

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

#51303

lawrencedo99@gmail.com writes:
> On Monday, September 26, 2016 at 11:04:43 AM UTC+13, Paul Rubin wrote:
>> The Arduino really does seem like a natural Forth target, though.
> I don’t think the Arduino can self-host any kind of development
> environment

Try amforth.sourceforge.net, written by Mathias Trute who is present in
this thread.  See also ulisp.com though that's much less practical.

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

#51311

On Monday, September 26, 2016 at 1:04:43 AM UTC+3, Paul Rubin wrote:
> 
> The Arduino really does seem like a natural Forth target, though.  It
> would be great if Amforth had more uptake.  Do you think of encouraging
> vendors of Atmel boards to ship with Amforth already installed?  Or
> maybe just flash a pile of Atmega328 parts and sell them to people?
> 
I am selling Atmega328 parts flashed with the latest version of FlashForth for the Arduino.

It is usually purchased by people who don't want to bother with flashing arrangements or compilation setup.

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

#51312

Mikael Nordman <oh2aun@gmail.com> writes:
> I am selling Atmega328 parts flashed with the latest version of
> FlashForth for the Arduino.

I had forgotten that FlashForth runs on the Arduino!  That's also good
to know.

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

#51313

Paul Rubin <no.email@nospam.invalid> wrote:
> 
> Recognizers seem like a good idea, even if there are issues still to
> work out.

Well, yes, that's the problem.  Lots of things seem like a good idea,
but have unexpected consequences.  Recognizers are probably the most
significant change to the Forth language that has (ever?) been
proposed, so a very high bar should be required for their adoption as
standard.

Andrew.

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

#51331

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> 
>> Recognizers seem like a good idea, even if there are issues still to
>> work out.
>
>Well, yes, that's the problem.  Lots of things seem like a good idea,
>but have unexpected consequences.  Recognizers are probably the most
>significant change to the Forth language that has (ever?) been
>proposed, so a very high bar should be required for their adoption as
>standard.

On the contrary, recognizers are not a change to the Forth language at
all.  They have been in Forth since day 1.  The very first Forth has
recognized 1 as number.

Ok, you might say, but that does not allow the user to add
recognizers.  However, users have been able to add recognizers of all
kinds to Forth systems for many decades.  E.g., if I look at the
floating point packages of SwiftForth, VFX, and Gforth, I see:

SwiftForth:
: FNUMBER? ( addr len 0 | ... xt -- addr len 0 | ... xt )
   ?DUP ?EXIT  BASE @ 10 = IF
      R-BUF  2DUP R@ PLACE  BL R@ COUNT + C!  R> (REAL) IF
         2DROP ['] FLITERAL  EXIT
   ELSE DROP THEN THEN 0 ;

' FNUMBER? NUMBER-CONVERSION <CHAIN

VFX:
defer old-number?
  action-of number? to-do old-number?

: fnumber?  	\ c-addr -- 0 | n 1 | d 2 | -2 ; F: -- r
\ *G Behaves like the integer version of *\fo{NUMBER?} except
\ ** that if  integer conversion fails, and *\fo{BASE} is decimal,
\ ** a floating point conversion is attempted. If conversion is
\ ** successful, the floating point number is left on the float
\ ** stack and the result code is -2.
  dup >r  old-number? dup 0= if		\ test for integer first
    base @ #10 = if			\ not integer, floats must be in DECIMAL
      drop  r@ count (>float)		\ >FLOAT returns well formed flag
      -2 and				\ good float returns -2,
    then
  then
  r> drop
;

assign fnumber? to-do number?
assign #fliteral to-do c#fliteral

Gforth 0.7.0:
:noname ( c-addr u -- ... xt )
    2dup sfnumber
    IF
	2drop [comp'] FLiteral
    ELSE
	defers compiler-notfound1
    ENDIF ;
IS compiler-notfound1

:noname ( c-addr u -- ... xt )
    2dup sfnumber
    IF
	2drop ['] noop
    ELSE
	defers interpreter-notfound1
    ENDIF ;
IS interpreter-notfound1


And just like the floating point recognizer can be added to these
Forth systems, every other recognizer can be added, too.

What the recognizer proposal does is to add a standardized interface
for adding recognizers and dealing with them, such that portable
libraries can provide recognizers.  But the basic capability has been
there in a non-portable way for decades.  There have been regular
discussions about providing a standardized interface for these
capabilities, demonstrating that there is demand for making such
things portable.  And at one point one of these discussions came up
with an embryonic version of the current recognizer proposal.

If you think that user-defined recognizers are a significant change to
Forth, you should have voiced your concerns when Forth, Inc, added the
NUMBER-CONVERSION chain, MPE made NUMBER? a deferred word (or whatever
it is), and when Gforth added NOTFOUND (the pre-predecessor of
COMPILER-NOTFOUND1 and INTERPRETER-NOTFOUND1).

- 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 2016: http://www.euroforth.org/ef16/

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

#51335

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Paul Rubin <no.email@nospam.invalid> wrote:
>>> 
>>> Recognizers seem like a good idea, even if there are issues still to
>>> work out.
>>
>>Well, yes, that's the problem.  Lots of things seem like a good idea,
>>but have unexpected consequences.  Recognizers are probably the most
>>significant change to the Forth language that has (ever?) been
>>proposed, so a very high bar should be required for their adoption as
>>standard.
> 
> On the contrary, recognizers are not a change to the Forth language
> at all.  They have been in Forth since day 1.  The very first Forth
> has recognized 1 as number.

I'm fairly sure it was never described in such a way.  I don't think
it's fair to use the term "recognizers" for both the recognizer
proposal and what Forths have always done.

> What the recognizer proposal does is to add a standardized interface
> for adding recognizers and dealing with them, such that portable
> libraries can provide recognizers.

I agree.  However, its scope is not limited to literals, and some
non-literal recognizers have been discussed here.  (e.g. the ">X"
syntax to mean "TO X").  I don't doubt that this has been possible
with some vendor-specific Forth code.  But there is a very significant
difference between something vendors do (and can be revised or removed
completely) and something which is standard, and therefore much harder
to remove if it turns out not to have been a good idea.

> But the basic capability has been there in a non-portable way for
> decades.

Great!  So all you have to do is persuade the authors of Forth
systems, particularly the professional vendors, to support the
proposal you favour on their systems.  And do that based on the actual
merits of what you propose.

Andrew.

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

#51420

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Paul Rubin <no.email@nospam.invalid> wrote:
>>>> 
>>>> Recognizers seem like a good idea, even if there are issues still to
>>>> work out.
>>>
>>>Well, yes, that's the problem.  Lots of things seem like a good idea,
>>>but have unexpected consequences.  Recognizers are probably the most
>>>significant change to the Forth language that has (ever?) been
>>>proposed, so a very high bar should be required for their adoption as
>>>standard.
>> 
>> On the contrary, recognizers are not a change to the Forth language
>> at all.  They have been in Forth since day 1.  The very first Forth
>> has recognized 1 as number.
>
>I'm fairly sure it was never described in such a way.

Maybe not.  Concepts evolve, and terms are introduced to go with that.
E.g., Luigi Galvani did not describe his discovery as
"bioelectromagnetics" ("electromagnetism" had not been discovered at
the time), yet <https://en.wikipedia.org/wiki/Electricity#History>
says: "In 1791, Luigi Galvani published his discovery of
bioelectromagnetics [...]".

>I don't think
>it's fair to use the term "recognizers" for both the recognizer
>proposal and what Forths have always done.

I think it's entirely fair.  When the difference plays a role, you can
add adjectives like "standardized", "system-pecific", "user-defined",
"system-defined", "extensible", and "non-extensible".

So what Forth systems have always done is to have a bunch of
standardized system-defined recognizers and system-specific hooks for
adding user-defined or more system-defined recognizers.  What is being
proposed came out of discussions for standardizing these hooks.

>I agree.  However, its scope is not limited to literals, and some
>non-literal recognizers have been discussed here.  (e.g. the ">X"
>syntax to mean "TO X").

Actually "->X".  Yes, that is possible with user-defined recognizers,
and it is also possible with the system-specific interpreter hooks
that Forth systems have always had.  And these system-specific hooks
have actually been used for non-literals, e.g., the dot-parser of VFX.
So that's nothing new that the recognizer proposal introduces.

>But there is a very significant
>difference between something vendors do (and can be revised or removed
>completely) and something which is standard, and therefore much harder
>to remove if it turns out not to have been a good idea.

As we have seen with "{", vendors do not revise or remove non-standard
words.  And as we have seen with LOCALS|, it is easy to de-standardize
words that turned out not to have been a good idea.

You can think only about removing any proposed feature, and when
that's your only goal, then yes, de-standardizing a feature that has
been standardized is harder than de-standardizing it if it has not
been.

Or you can think about what benefits the proposed feature would
provide, what costs it would impose on system implementors and program
readers, if the proposed interface is good or if you can suggest
improvements.

I don't think an attitude that only takes de-standardization into
consideration is cunducive to the aim of having programs and libraries
that are portable between systems.  The latter is certainly an aim I
am pursuing.  What aims are you pursuing?

- 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 2016: http://www.euroforth.org/ef16/

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

#51425

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Paul Rubin <no.email@nospam.invalid> wrote:
>>>>> 
>>>>> Recognizers seem like a good idea, even if there are issues still to
>>>>> work out.
>>>>
>>>>Well, yes, that's the problem.  Lots of things seem like a good idea,
>>>>but have unexpected consequences.  Recognizers are probably the most
>>>>significant change to the Forth language that has (ever?) been
>>>>proposed, so a very high bar should be required for their adoption as
>>>>standard.
>>> 
>>> On the contrary, recognizers are not a change to the Forth language
>>> at all.  They have been in Forth since day 1.  The very first Forth
>>> has recognized 1 as number.
>>
>>I'm fairly sure it was never described in such a way.
> 
> Maybe not.  Concepts evolve, and terms are introduced to go with that.

I'm sure, but I need perhaps to explain that when I talk about
"recognizers" I'm talking bout the recognizer proposal on the table.

>>I don't think it's fair to use the term "recognizers" for both the
>>recognizer proposal and what Forths have always done.
> 
> I think it's entirely fair.

There we will have to agree to differ.

> When the difference plays a role, you can add adjectives like
> "standardized", "system-pecific", "user-defined", "system-defined",
> "extensible", and "non-extensible".
> 
> So what Forth systems have always done is to have a bunch of
> standardized system-defined recognizers and system-specific hooks for
> adding user-defined or more system-defined recognizers.  What is being
> proposed came out of discussions for standardizing these hooks.

Indeed.

>>I agree.  However, its scope is not limited to literals, and some
>>non-literal recognizers have been discussed here.  (e.g. the ">X"
>>syntax to mean "TO X").
> 
> Actually "->X".  Yes, that is possible with user-defined recognizers,
> and it is also possible with the system-specific interpreter hooks
> that Forth systems have always had.  And these system-specific hooks
> have actually been used for non-literals, e.g., the dot-parser of VFX.
> So that's nothing new that the recognizer proposal introduces.

No, that is not true.  It adds to the standard language a feature
which allows libraries to add arbitrary strings to the source
language, and for each library to define its own set of strings which
will be recognized.  And not only to change the meaning of words but
also to change the way that source strings are scanned.  I do not deny
that this was possible already in some Forth systems, but we are
talking about a proposal for standardization.  I suspect that it
wasn't standardized, even though some systems have system-specific
hooks, because it is inherently highly problematic.

>>But there is a very significant difference between something vendors
>>do (and can be revised or removed completely) and something which is
>>standard, and therefore much harder to remove if it turns out not to
>>have been a good idea.
> 
> As we have seen with "{", vendors do not revise or remove non-standard
> words.  And as we have seen with LOCALS|, it is easy to de-standardize
> words that turned out not to have been a good idea.
> 
> You can think only about removing any proposed feature, and when
> that's your only goal, then yes, 

Destandardizing a feature that has been standardized is harder than
destandardizing it if it has not been.  This is true no matter what
you're thinking about.

> Or you can think about what benefits the proposed feature would
> provide, what costs it would impose on system implementors and program
> readers, if the proposed interface is good or if you can suggest
> improvements.

That sounds very sensible.

> I don't think an attitude that only takes de-standardization into
> consideration is cunducive to the aim of having programs and libraries
> that are portable between systems.

Neither do I.  Nobody does, as far as I'm aware.

> The latter is certainly an aim I am pursuing.  What aims are you
> pursuing?

The issue here isn't only writing portable libraries.  There is also
the coherence, readability, and maintainability of programs to
consider.  This proposal is very general and might not help people to
write portable libraries at all.  In fact, recognizers in libraries
have the potential of changing a language which is, at base, words and
literals into an incomprehensible alphabet soup with insufficient
tools to understand the resulting confusion.  And this will work
*against* the adoption of portable libraries.

I repeat my earlier comment: you are trying to jump the starting gun.
If you want a proposal to be standardized, you should persuade
implementers to use it in their systems and programmers to try it.
And you must do so on its own merits.  If a proposal has significant
benefits for them and their users then they will want to do that
anyway.

Andrew.

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

#51333

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Quotations are neat, but they don't add a great deal of power to the
>language.  On the other hand, their cost and footprint is small.  I
>think that they'll turn out to be useful enough to be standardized,
>but once a word is in the standard it's hard to get rid of it.

Currently it is much easier to get rid of words than to add words;
admittedly, for the getting-rid part to actually take effect takes a
lot of time, but the amount of work required is smaller by several
orders of magnitude:

For getting rid of a word, you don't even need to make an RfD; someone
proposes to make the word obsolescent at a meeting, without providing
any numbers on usage or anything, the committee takes a vote, and the
word is obsolescent, and will be gone in the next-but-one standard
unless there is a concerted effort to keep it in, as happened for
FORGET (and even then the committee decided to keep it obsolescent, so
the fans of FORGET may have to make the same effort the next time).
This has happened to LOCALS| and [COMPILE], and almost to (LOCAL).

For adding a word, you can jump through all the hoops, write a
proposal, get it voted on, have implementations for several Forth
systems, demonstrate that the programmers feel that there is a need
for it by resorting to return-address manipulation to get the feature,
show a count of how many times the proposed form of the feature is
used, answer all the questions that the committee has about the
proposal (with an explicit "no" to the question whether there are
further questions), and on committee vote the proposal fails to get
consensus.  This has happened to quotations.

- 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 2016: http://www.euroforth.org/ef16/

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

#51338

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Quotations are neat, but they don't add a great deal of power to the
>>language.  On the other hand, their cost and footprint is small.  I
>>think that they'll turn out to be useful enough to be standardized,
>>but once a word is in the standard it's hard to get rid of it.
> 
> Currently it is much easier to get rid of words than to add words;
> admittedly, for the getting-rid part to actually take effect takes a
> lot of time, but the amount of work required is smaller by several
> orders of magnitude:

By "it's hard" I don't necessarily mean that it's less work: I mean
that it is difficult (perhaps impossible) to get rid of a feature once
it is in use in applications because -- quite rightly -- people tend
to treat not breaking code as very important.

Andrew.

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

#51346

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>but once a word is in the standard it's hard to get rid of it.
>> 
>> Currently it is much easier to get rid of words than to add words;
>> admittedly, for the getting-rid part to actually take effect takes a
>> lot of time, but the amount of work required is smaller by several
>> orders of magnitude:
>
>By "it's hard" I don't necessarily mean that it's less work: I mean
>that it is difficult (perhaps impossible) to get rid of a feature once
>it is in use in applications because -- quite rightly -- people tend
>to treat not breaking code as very important.

What you describe is they way it should work.  But it actually does
not work that way.  It actually works the way I described in the part
that you conveniently deleted, so here it is again:

|For getting rid of a word, you don't even need to make an RfD; someone
|proposes to make the word obsolescent at a meeting, without providing
|any numbers on usage or anything, the committee takes a vote, and the
|word is obsolescent, and will be gone in the next-but-one standard
|unless there is a concerted effort to keep it in, as happened for
|FORGET (and even then the committee decided to keep it obsolescent, so
|the fans of FORGET may have to make the same effort the next time).
|This has happened to LOCALS| and [COMPILE], and almost to (LOCAL).

So while parts of the committee are extremely reluctant when it comes
to adding new words (because it is supposedly so difficult to get rid
of them), the committee is quite keen on making words obsolescent
(which leads to deletion from the standard in a later version), and
does not do any research about the usage of the word in applications
before taking that decision.

A nice example is LOCALS|.  It was added in Forth-94, and was not a
good solution, so it was declared obsolescent in Forth-2012 and will
be removed from the standard in the next version.  This was not at all
difficult.

What actually is difficult is getting a de-standardized word really
out of use, as we have seen in occasional discussions of NOT.  But
such problems can just as well occur if the word has never been
standardized; example: "{".

- 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 2016: http://www.euroforth.org/ef16/

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

#51367

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>but once a word is in the standard it's hard to get rid of it.
>>> 
>>> Currently it is much easier to get rid of words than to add words;
>>> admittedly, for the getting-rid part to actually take effect takes a
>>> lot of time, but the amount of work required is smaller by several
>>> orders of magnitude:
>>
>>By "it's hard" I don't necessarily mean that it's less work: I mean
>>that it is difficult (perhaps impossible) to get rid of a feature once
>>it is in use in applications because -- quite rightly -- people tend
>>to treat not breaking code as very important.
> 
> What you describe is they way it should work.  But it actually does
> not work that way.  It actually works the way I described in the part
> that you conveniently deleted, so here it is again:

I will again cite FORGET as the counter-example.

> |For getting rid of a word, you don't even need to make an RfD; someone
> |proposes to make the word obsolescent at a meeting, without providing
> |any numbers on usage or anything, the committee takes a vote, and the
> |word is obsolescent, and will be gone in the next-but-one standard
> |unless there is a concerted effort to keep it in, as happened for
> |FORGET (and even then the committee decided to keep it obsolescent, so
> |the fans of FORGET may have to make the same effort the next time).
> |This has happened to LOCALS| and [COMPILE], and almost to (LOCAL).
> 
> So while parts of the committee are extremely reluctant when it comes
> to adding new words (because it is supposedly so difficult to get rid
> of them), the committee is quite keen on making words obsolescent
> (which leads to deletion from the standard in a later version),

Good.  Forth is a small language.  It should be easier to remove
standard features than to add them.

> and does not do any research about the usage of the word in
> applications before taking that decision.

I think that's a bit of a stretch.

> What actually is difficult is getting a de-standardized word really
> out of use, as we have seen in occasional discussions of NOT.  But
> such problems can just as well occur if the word has never been
> standardized; example: "{".

My point stands.  If a word is in the standard, it's much harder to
de-standardize it than if it is not in the standard.  

Andrew.

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

#51370

On 26/09/16 17:02, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Quotations are neat, but they don't add a great deal of power to the
>>> language.  On the other hand, their cost and footprint is small.  I
>>> think that they'll turn out to be useful enough to be standardized,
>>> but once a word is in the standard it's hard to get rid of it.
>>
>> Currently it is much easier to get rid of words than to add words;
>> admittedly, for the getting-rid part to actually take effect takes a
>> lot of time, but the amount of work required is smaller by several
>> orders of magnitude:
>
> By "it's hard" I don't necessarily mean that it's less work: I mean
> that it is difficult (perhaps impossible) to get rid of a feature once
> it is in use in applications because -- quite rightly -- people tend
> to treat not breaking code as very important.
>
> Andrew.
>

The "not breaking code" argument doesn't necessarily win by saying it's 
very important. It has to demonstrate that stability is vital.

Currently there's a pretty heated argument over Docker about release 
compatibility & standards. Docker Inc. seem to believe that breaking 
code is not only OK, but that it's desirable -- nay, vital.

http://www.infoworld.com/article/3105857/open-source-tools/save-the-whale-docker-rightfully-shuns-standardization.html

-- 
Alex

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

#51339 — Standardization (was: Essential properties of current standard Forth)

Matthias Trute <matthias.trute@gmail.com> writes:
>I think that's the consequence of the design principle of the Forth
>standard process: codify existing practice and consolidate it. Other
>standard bodies follow a different approach: define something and declare
>it standard, or standard extension. E.g. the WLAN or Ethernet standards
>follow this model. First you get the specs, the implementation follows.
>
>Forth could use both. There is a core feature set like the stacks, some wor=
>ds (in CORE) and the interpreter/compile model, and there are a number of e=
>xtension wordsets. These extension wordsets could be managed more freely th=
>an the core.

Well, we have that already.  We have the CORE wordset, and IIRC
nothing has been added to it or removed from it between Forth-94 and
Forth-2012 except a feature or two already declared obsolescent in
Forth-94 (space at the end of the WORD buffer IIRC).  The only thing
that was really added to the core in Forth-2012 is number prefixes,
and that's because making them optional would have turned the document
into an ifdef maze.

All the extension wordsets are optional.  But even adding things to
extension wordsets is very tough going, to put it mildly.

So in the latest meeting the committee has decided to encourage
"experimental proposals".  It's not quite clear to me how that differs
from an ordinary RfD, but my impression is the idea is to put up
another hoop for proponents so that the ossified standard can be
protected from dangerous ideas.

My take on this is to revert back to the original idea of the RfD/CfV
process: Have an RfD phase where you hash out the proposal, and when
you think you have a good and as widely acceptable as possible
proposal, freeze it and make a CfV; and because it is frozen, now more
systems can implement it (or one can have implementations for systems
where the maintainers are unwilling), and users can use it, and one
can indicate the level of support of the proposal in the votes (and
maybe one day also in the number of dependences on theforth.net).  If
the proposal does not get accepted into the standard, but is widely
supported and used, the only consequence is that you have to look it
up in the CfV (and that the standard makes itself less relevant).

>They fol=
>low the TurboPascal model, hopefully with better luck.

I think we could all wish that any Forth system had as much luck as
Turbo Pascal.

- 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 2016: http://www.euroforth.org/ef16/

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

#51344 — Re: Standardization (was: Essential properties of current standard Forth)

On Mon, 26 Sep 2016 16:01:16 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>So in the latest meeting the committee has decided to encourage
>"experimental proposals".  It's not quite clear to me how that differs
>from an ordinary RfD, but my impression is the idea is to put up
>another hoop for proponents so that the ossified standard can be
>protected from dangerous ideas.

The remit of the standard is to codify common practice. This means
that the practice to be standardised is widespread. The idea of 
experimental proposals is to allow proposals for new practice to be
taken seriously. and perhaps to become common practice.

Regardless of the 1984-style redefinition of the mean of
"recognition", recognisers are not widespread at present. They
are a perfect example of experimental practice, and by having a
formal proposal, systems are encouraged to experiment with them.

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]

#51390 — Re: Standardization (was: Essential properties of current standard Forth)

stephen@mpeforth.com (Stephen Pelc) writes:
>On Mon, 26 Sep 2016 16:01:16 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>So in the latest meeting the committee has decided to encourage
>>"experimental proposals".  It's not quite clear to me how that differs
>>from an ordinary RfD, but my impression is the idea is to put up
>>another hoop for proponents so that the ossified standard can be
>>protected from dangerous ideas.
>
>The remit of the standard is to codify common practice. This means
>that the practice to be standardised is widespread. The idea of 
>experimental proposals is to allow proposals for new practice to be
>taken seriously. and perhaps to become common practice.

You mean, until now you don't take RfDs for new practice seriously,
but once the "experimental proposal" sticker is put on it, you will?

>Regardless of the 1984-style redefinition of the mean of
>"recognition", recognisers are not widespread at present. They
>are a perfect example of experimental practice, and by having a
>formal proposal, systems are encouraged to experiment with them.

Sure.  That proposal is at the RfD stage, so accepting it into the
standard is not even on the table.  However, what I am missing is the
willingness for experimentation, and using the face-to-face time that
you think is so valuable for hashing out technical (or documentation)
issues.  Given that, your reaction will be the same next year, in five
years, in twenty years, etc.

As for recognizers not being widespread, they are present in at least
two systems, more than the Text Substitution proposal when it was put
up for committee vote, and maybe as many as the Text Substitution
proposal is implemented in now.  So, when the proposal reaches
stability (CfV stage), that level of spreading should be enough for
you to accept it.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#51391 — Re: Standardization

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> stephen@mpeforth.com (Stephen Pelc) writes:
>>On Mon, 26 Sep 2016 16:01:16 GMT, anton@mips.complang.tuwien.ac.at
>>(Anton Ertl) wrote:
>>
>>>So in the latest meeting the committee has decided to encourage
>>>"experimental proposals".  It's not quite clear to me how that differs
>>>from an ordinary RfD, but my impression is the idea is to put up
>>>another hoop for proponents so that the ossified standard can be
>>>protected from dangerous ideas.
>>
>>The remit of the standard is to codify common practice. This means
>>that the practice to be standardised is widespread. The idea of 
>>experimental proposals is to allow proposals for new practice to be
>>taken seriously. and perhaps to become common practice.
> 
> You mean, until now you don't take RfDs for new practice seriously,
> but once the "experimental proposal" sticker is put on it, you will?

That sounds reasonable.  All that "RfD" means is that someone
considers something worth discussing.  An Experimental Proposal is
something that the committee as a body thinks is a real candidate for
standardization.

Andrew.

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

#51436 — Re: Standardization (was: Essential properties of current standard Forth)

On Tue, 27 Sep 2016 14:49:12 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>stephen@mpeforth.com (Stephen Pelc) writes:
>>The remit of the standard is to codify common practice. This means
>>that the practice to be standardised is widespread. The idea of 
>>experimental proposals is to allow proposals for new practice to be
>>taken seriously. and perhaps to become common practice.
>
>You mean, until now you don't take RfDs for new practice seriously,
>but once the "experimental proposal" sticker is put on it, you will?

There are so many ideas to be tried that, as always, we encourage
natural selection by asking a "champion" to put a proposal together.
>
>>Regardless of the 1984-style redefinition of the mean of
>>"recognition", recognisers are not widespread at present. They
>>are a perfect example of experimental practice, and by having a
>>formal proposal, systems are encouraged to experiment with them.
>
>Sure.  That proposal is at the RfD stage, so accepting it into the
>standard is not even on the table.  However, what I am missing is the
>willingness for experimentation, and using the face-to-face time that
>you think is so valuable for hashing out technical (or documentation)
>issues.  Given that, your reaction will be the same next year, in five
>years, in twenty years, etc.

The file Examples/recogniser.fth is in all VFX distributions.
Personally I will look at recognisers in my ample spare time.
However, recognisers implicitly suggest a major restructuring
of the Forth text interpreter. That veers towards mandating
implementation, which worries me. There are other committee
members who have expressed worry in public. 

>As for recognizers not being widespread, they are present in at least
>two systems, more than the Text Substitution proposal when it was put
>up for committee vote, and maybe as many as the Text Substitution
>proposal is implemented in now.  So, when the proposal reaches
>stability (CfV stage), that level of spreading should be enough for
>you to accept it.

You didn't have to vote for it. SUBSTITUTE has the benefit of nearly
20 years usage in MPE's ProForth and VFX lines. Text macro
substitution exists in all Unix shells and other languages. It has
been in the internationalisation proposal for 18 years.

That you see no benefit to it suggests that you do not write
internationalised applications. It is already clear that Anton and
Stephen have very different views on source file naming and
management.

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]

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

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

csiph-web