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

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

RfD: new double syntax

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

Contents

  RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-01 17:18 +0000
    Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 11:45 -0700
      Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-01 14:46 -0400
    Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-01 11:47 -0700
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:54 +0000
    Re: RfD: new double syntax mhx@iae.nl - 2016-07-01 11:48 -0700
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:52 +0000
    Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-01 09:10 -1000
      Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 19:10 -0700
        Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 06:23 +0000
    RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-01 20:54 -0700
      RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-01 21:18 -0700
        Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 22:26 -0700
          Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 22:32 +0000
            Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 01:16 -0400
              Re: RfD: new double syntax Ron Aaron <rambamist@gmail.com> - 2016-07-03 08:34 +0300
                Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 03:00 -0400
                  Re: RfD: new double syntax Ron Aaron <rambamist@gmail.com> - 2016-07-03 10:20 +0300
                  Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 08:29 +0000
              Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 23:10 -0700
                Re: RfD: new double syntax Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-02 23:20 -0700
                  Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 03:02 -0400
        Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:20 +0000
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:11 +0000
    Re: RfD: new double syntax josv@planet.nl - 2016-07-02 00:26 -0700
      Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-01 22:22 -1000
        Re: RfD: new double syntax "HAA" <someone@microsoft.com> - 2016-07-02 22:02 +1000
          Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 11:19 -1000
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:02 +0000
    Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-02 04:03 -0500
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 13:44 +0000
        Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 07:38 -0700
          Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 07:42 -0700
          Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 22:44 +0000
        Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-02 09:58 -0500
        Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 11:32 -1000
        Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-03 00:27 +0000
        Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 08:05 -0700
        Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 03:50 -0500
          Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 03:53 -0500
    Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 17:32 +0000
      Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-02 10:52 -0700
        Re: RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-02 13:03 -0700
        Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 15:02 +0000
          Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-03 11:18 -0700
            Re: RfD: new double syntax Coos Haak <chforth@hccnet.nl> - 2016-07-03 21:19 +0200
      Re: RfD: new double syntax Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 11:36 +0100
        Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-03 06:58 -0700
          Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 14:21 +0000
            Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-03 07:55 -0700
            Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-03 08:08 -0700
              Dealing with multiple recognizers (was: RfD: new double syntax) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 15:13 +0000
                Re: Dealing with multiple recognizers (was: RfD: new double syntax) hughaguilar96@gmail.com - 2016-07-03 09:57 -0700
            Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-05 01:12 -0400
              Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-05 07:56 -0700
                Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-05 11:18 -0400
          Re: RfD: new double syntax JennyB <jennybrien@googlemail.com> - 2016-07-03 08:15 -0700
          Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-03 12:42 -0500
            Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-03 09:32 -1000
              Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 07:34 -0700
            Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-04 10:35 -0700
            Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-04 09:00 -0700
              Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 09:51 -0700
            Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 11:20 -0500
              Re: RfD: new double syntax Howerd <howerdo@yahoo.co.uk> - 2016-07-06 04:08 -0700
                Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 06:24 -0500
                  Re: RfD: new double syntax Alex McDonald <alex@rivadpm.com> - 2016-07-06 12:38 +0100
                    Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 06:46 -0500
                  Re: RfD: new double syntax Howerd <howerdo@yahoo.co.uk> - 2016-07-06 13:37 -0700
                    Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-07 03:28 -0500
                      Re: RfD: new double syntax Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-04 23:59 +0000
                        Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 19:26 -0500
                      Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-04 17:34 -0700
                        Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-05 02:57 -0700
                          Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-05 13:15 -0700
                            Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-06 01:56 -0700
                              Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-07 17:22 -0700
                                Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-08 04:56 -0700
                                  Re: RfD: new double syntax josv@planet.nl - 2016-08-08 08:50 -0700
                                    Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-08 12:26 -0700
                                      Re: RfD: new double syntax josv@planet.nl - 2016-08-08 15:41 -0700
                                        Re: RfD: new double syntax mhx@iae.nl - 2016-08-08 23:06 -0700
                                          Re: RfD: new double syntax josv@planet.nl - 2016-08-09 00:57 -0700
                                        Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-09 03:05 -0700
                                          Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-08-10 01:46 -0700
                                  Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-10 19:07 -0700
                                    Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-11 05:24 -0700
                          Re: RfD: new double syntax josv@planet.nl - 2016-08-06 04:50 -0700
                        Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-05 12:01 -0500
            Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-04 08:51 -0500
            Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 04:03 -0500
        Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 14:56 +0000
          Re: RfD: new double syntax Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 22:00 +0100

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

#48707

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Problem
>-------
>
>People coming from other languages expect "1." to be a floating-point
>number.  Standard Forth requires that "1." is interpreted as a
>double-wide integer number.  While some people hail every gratuitious
>difference from other languages as a sign of our independence, this
>makes Forth harder to teach and damages the reputation among
>newcomers: First when they trip across this trap, and further when
>they hear about the reason for this behaviour.
>
>
>Solution
>--------
>
>In the long term, make "1." either non-standard or (even longer-term)
>even make it a floating-point number in the standard.  However, we
>still need a syntax for double-wide integers, and we need to introduce
>this first (and in parallel to the "1." syntax).  So here I propose
>using the syntax "*1" for double-wide integers.

Bernd Paysan suggested an alternative solution: Just make unprefixed
doubles obsolescent (and eventually non-standard), but instead of
adding a new prefix for doubles, just require one of the existing
prefixes if you want to write a double.  I.e.,:

1.  \ proposed obsolescent, eventually non-standard
#1. \ double
$1. \ double
%1. \ double

That should satisfy those who object to the "*1" syntax on aesthetic
reasons.  It also has the advantage that people can start converting
without first having to wait for systems that support "*1"; the "#1."
syntax is already supported.

>Experience
>----------
>
>None.

Prefixes have been around for many years and have been standardized in
Forth-2012.

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

#48709

On Saturday, July 2, 2016 at 12:43:39 PM UTC-5, Anton Ertl wrote:
> 
> Bernd Paysan suggested an alternative solution: Just make unprefixed
> doubles obsolescent (and eventually non-standard), but instead of
> adding a new prefix for doubles, just require one of the existing
> prefixes if you want to write a double.  I.e.,:
> 
> 1.  \ proposed obsolescent, eventually non-standard
> #1. \ double
> $1. \ double
> %1. \ double
> 
> That should satisfy those who object to the "*1" syntax on aesthetic
> reasons.  It also has the advantage that people can start converting
> without first having to wait for systems that support "*1"; the "#1."
> syntax is already supported.
> 

Part of the reply I was coming up with was: why not have your students
use a version of gforth that disables doubles?  Bernd's suggestion is
even better.  You can require that people load a library first that
changes the recognizer stack to disable unprefixed doubles, and then
bring this up -- and why you're doing it -- at some point.  And then
your problem is pretty much solved.

Why does it need to remain a problem of the standard?


-- Julian

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

#48713

Julian Fondren wrote:
...
> Why does it need to remain a problem of the standard? 

Having done a considerable amount of floating point programming in Forth, I can tell you from my personal experience that the trailing decimal notation for double numbers is indeed a problem. It is too ingrained from working in other languages to avoid writing "1." when it was intended to write, "1.0e0". This is why I chose not to implement interpretation of double length numbers in kForth, from almost the beginning. Even then, I found myself entering numbers with only a trailing decimal point, but this error was at least caught by the interpreter. The double number input specification is an anachronism from the days when floating point wasn't an expected component of Forth systems. The possibility of an intended fp number being interpreted as a double number is the primary reason in my mind as to why it should be eliminated in a modern Forth standard.

Krishna

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

#48753

Julian Fondren <julian.fondren@gmail.com> writes:
>On Saturday, July 2, 2016 at 12:43:39 PM UTC-5, Anton Ertl wrote:
>> 
>> Bernd Paysan suggested an alternative solution: Just make unprefixed
>> doubles obsolescent (and eventually non-standard), but instead of
>> adding a new prefix for doubles, just require one of the existing
>> prefixes if you want to write a double.  I.e.,:
>> 
>> 1.  \ proposed obsolescent, eventually non-standard
>> #1. \ double
>> $1. \ double
>> %1. \ double
>> 
>> That should satisfy those who object to the "*1" syntax on aesthetic
>> reasons.  It also has the advantage that people can start converting
>> without first having to wait for systems that support "*1"; the "#1."
>> syntax is already supported.
>> 
>
>Part of the reply I was coming up with was: why not have your students
>use a version of gforth that disables doubles?  Bernd's suggestion is
>even better.  You can require that people load a library first that
>changes the recognizer stack to disable unprefixed doubles, and then
>bring this up -- and why you're doing it -- at some point.

How do you imagine I can require that of my students?  They install
Gforth from somewhere, and the run it.  If it is not there on startup,
teaching them to reliably type "gforth student-setup.fs" or something
is going to cost about as much time as teaching them about "1." in the
first place, and is equally unproductive.

>Why does it need to remain a problem of the standard?

Are my students the only newcomers we are expecting in the Forth
community?  My students at least have me to ask why their program that
uses "1." is not working as they expected; many others are on their
own.

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

#48762

On Sunday, July 3, 2016 at 10:09:28 AM UTC-5, Anton Ertl wrote:
> 
> How do you imagine I can require that of my students?
>

"Here, have this library" ?
"Get gforth from this location" ?
"Before you do anything else with gforth, run CRIPPLED-DOUBLES" ?
Or make that the default in the next release.

> Are my students the only newcomers we are expecting in the Forth
> community?

There are multiple contributors to the situation of someone entering 1.
and then having a hard time of things.  When you place your finger on
any one contributor, you may think of solutions geared towards
countering or modifying that particular kind of contribution.  When we
talk about your students, one contributor is your instruction, and
solutions could involve better ways of instructing them.  "Don't tell
them to write programs before covering the basic syntax of the
language", for example.  Maybe a one-page cheat-sheet would be handy.

There are also technological contributors, that Forth's debuggers aren't
all they could be, that little information (not even the contents or
depths of the stacks in gforth's case) is given on error, that you're
typing in a terminal with "ok" or perhaps "compiled" as your only
feedback when a more newbie-friendly graphical interface might have a
running display of the stack, and so on, which all might inspire
technological answers.  Maybe some limited type information could be
kept for purely advisory purposes, so that .S can display doubles and
strings as a coherent object instead of as two cells.

You can also teach a pidgin language that's very similar to Forth, and
then teach the differences between that language and Forth.  (I thought
DrScheme did this, but documentation these days doesn't emphasize the
pedagogical value of their dialects.)  Forth+doubles is not going to be
a serious challenge, once one has thoroughly learned Forth-doubles.

For some reason you've settled on the language itself as the easiest
thing to change.  This is bizarre enough that one seeks out alternate
explanations.  Like, maybe you've lost faith in the Forth-200x process,
so you set a challenge for yourself: get something incredibly simple and
easy pushed through, that clearly benefits the language, and get it
actually widely adopted.  If that works, then OK, there's still some
life left.  Well, if so, this doesn't "clearly benefit the language"
and it's definitely not going to get widely adopted except as an option
that has to be turned on and which will never go away.

Here's another conspiracy theory: present something that changes the
syntax of the language, which would clearly benefit the language but
which can't possibly be accepted for compatibility reasons.  When people
agree that "yes, that would be nice, but we can't do it", present
recognizers as the obvious savior, giving us beneficial things without
breaking old code.  Again, if so, I don't think "that would be nice" is
clear enough with doubles.

With all of that said, this is clearly the best alternate notation for
doubles:

  1,

:^)


-- Julian

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

#48763

Op Sun, 3 Jul 2016 11:18:11 -0700 (PDT) schreef Julian Fondren:

> On Sunday, July 3, 2016 at 10:09:28 AM UTC-5, Anton Ertl wrote:
>> 
>> How do you imagine I can require that of my students?
>>
> 
> "Here, have this library" ?
> "Get gforth from this location" ?
> "Before you do anything else with gforth, run CRIPPLED-DOUBLES" ?
> Or make that the default in the next release.
> 
>> Are my students the only newcomers we are expecting in the Forth
>> community?
> 
> There are multiple contributors to the situation of someone entering 1.
> and then having a hard time of things.  When you place your finger on
> any one contributor, you may think of solutions geared towards
> countering or modifying that particular kind of contribution.  When we
> talk about your students, one contributor is your instruction, and
> solutions could involve better ways of instructing them.  "Don't tell
> them to write programs before covering the basic syntax of the
> language", for example.  Maybe a one-page cheat-sheet would be handy.
> 
> There are also technological contributors, that Forth's debuggers aren't
> all they could be, that little information (not even the contents or
> depths of the stacks in gforth's case) is given on error, that you're
> typing in a terminal with "ok" or perhaps "compiled" as your only
> feedback when a more newbie-friendly graphical interface might have a
> running display of the stack, and so on, which all might inspire
> technological answers.  Maybe some limited type information could be
> kept for purely advisory purposes, so that .S can display doubles and
> strings as a coherent object instead of as two cells.
> 
> You can also teach a pidgin language that's very similar to Forth, and
> then teach the differences between that language and Forth.  (I thought
> DrScheme did this, but documentation these days doesn't emphasize the
> pedagogical value of their dialects.)  Forth+doubles is not going to be
> a serious challenge, once one has thoroughly learned Forth-doubles.
> 
> For some reason you've settled on the language itself as the easiest
> thing to change.  This is bizarre enough that one seeks out alternate
> explanations.  Like, maybe you've lost faith in the Forth-200x process,
> so you set a challenge for yourself: get something incredibly simple and
> easy pushed through, that clearly benefits the language, and get it
> actually widely adopted.  If that works, then OK, there's still some
> life left.  Well, if so, this doesn't "clearly benefit the language"
> and it's definitely not going to get widely adopted except as an option
> that has to be turned on and which will never go away.
> 
> Here's another conspiracy theory: present something that changes the
> syntax of the language, which would clearly benefit the language but
> which can't possibly be accepted for compatibility reasons.  When people
> agree that "yes, that would be nice, but we can't do it", present
> recognizers as the obvious savior, giving us beneficial things without
> breaking old code.  Again, if so, I don't think "that would be nice" is
> clear enough with doubles.
> 
> With all of that said, this is clearly the best alternate notation for
> doubles:
> 
>   1,

As all the words ending in comma have to do with compiling, its a bad idea.
On the other hand, ciforth uses comma to group digits in numbers,
without forcing them to doubles. For that use a period.
1,000,000 is a single million
1,000,000,000 is a single milliard.
(A billion is 10e12, I'm European, we have long numbers)

> 
>:^)
> 
> 
> -- Julian

groet Coos

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

#48744

On 02/07/2016 18:32, Anton Ertl wrote:
> Bernd Paysan suggested an alternative solution: Just make unprefixed
> doubles obsolescent (and eventually non-standard), but instead of
> adding a new prefix for doubles, just require one of the existing
> prefixes if you want to write a double.  I.e.,:
>
> 1.  \ proposed obsolescent, eventually non-standard
> #1. \ double
> $1. \ double
> %1. \ double

How would a double integer be entered in a base without a prefix? 
Perhaps your *1. would do for that where the * is regarded as a wild 
card base rather than an arithmetic operator.

-- 
Gerry

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

#48747

Hello from an unexperience reader,
Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double.
The point character would be the default value letting old programs running.
For those who want to use another char it will be set at the beginning.
Candidates (for me) are underscore, caret and backslash

Gérard

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

#48749

Gerard Sontag <gerardsontag@gmail.com> writes:
>Hello from an unexperience reader,
>Why not create a new VARIABLE (name TBD) which will contain the preferred c=
>har indicating double.

A bad idea, like BASE.  You then have a bunch of programs written in
mutually incompatible Forth dialects, where you have to set TBD at
each file start and/or save and restore it before any INCLUDE and/or
at the start and end of every file.  And because there will be no
common convention, programmers will leave all this complicated stuff
away in the name of simplicity (except maybe setting TBD to a
non-default value, but they will certainly leave setting it to the
default value away), so combining independently developed libraries
will become even more problematic than it is now.

Of course, like many bad ideas, this one has been implemented in a
Forth system, under the name DP-CHAR, not TBD.  DP-CHAR is a little
better then TBD by being able to hold up to four characters, but AFAIK
there is no word to make joining another character to the set easy.

>The point character would be the default value letting old programs running=
>.

Which will do nothing to solve the problem that this RfD attacks.

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

#48750

Le dimanche 3 juillet 2016 16:39:01 UTC+2, Anton Ertl a écrit :
> Gerard Sontag <gerardsontag@gmail.com> writes:
> >Hello from an unexperience reader,
> >Why not create a new VARIABLE (name TBD) which will contain the preferred c=
> >har indicating double.
> 
> A bad idea, like BASE.  You then have a bunch of programs written in
> mutually incompatible Forth dialects, where you have to set TBD at
> each file start and/or save and restore it before any INCLUDE and/or
> at the start and end of every file.  And because there will be no
> common convention, programmers will leave all this complicated stuff
> away in the name of simplicity (except maybe setting TBD to a
> non-default value, but they will certainly leave setting it to the
> default value away), so combining independently developed libraries
> will become even more problematic than it is now.
> 
> Of course, like many bad ideas, this one has been implemented in a
> Forth system, under the name DP-CHAR, not TBD.  DP-CHAR is a little
> better then TBD by being able to hold up to four characters, but AFAIK
> there is no word to make joining another character to the set easy.
> 
> >The point character would be the default value letting old programs running=
> >.
> 
> Which will do nothing to solve the problem that this RfD attacks.
> 
> - 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/

Hello,
By TBD i mean To Be Defined (a common name in vaporware and unfinished business presentations like in "Operations Manager: TBD")
I think that BASE was a very good idea anyway.

Gérard

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

#48752

On Sunday, July 3, 2016 at 7:39:01 AM UTC-7, Anton Ertl wrote:
> Gerard Sontag <gerardsontag@gmail.com> writes:
> >Hello from an unexperience reader,
> >Why not create a new VARIABLE (name TBD) which will contain the preferred c=
> >har indicating double.
> 
> A bad idea, like BASE.  You then have a bunch of programs written in
> mutually incompatible Forth dialects, where you have to set TBD at
> each file start and/or save and restore it before any INCLUDE and/or
> at the start and end of every file.  And because there will be no
> common convention, programmers will leave all this complicated stuff
> away in the name of simplicity (except maybe setting TBD to a
> non-default value, but they will certainly leave setting it to the
> default value away), so combining independently developed libraries
> will become even more problematic than it is now.

In this thread,
https://groups.google.com/forum/#!searchin/comp.lang.forth/EuroForth$202016/comp.lang.forth/D0PmblPgthM/iyZvwPgoDwAJ
I said this:
On Wednesday, May 4, 2016 at 5:03:16 PM UTC-7, hughag...@gmail.com wrote:
> Another big mistake in Forth-200x is this push for "recognizers." This is an effort to give Forth a syntax, but straight Forth (here I mean "straight" in the sense of "traditional") doesn't have syntax. Recognizers are a can of ambiguous worms that are likely to contradict each other and will cause incompatibility! At the very least, they are going to cause total bewilderment for some poor devil who looks at a Forth program that relies on a mish-mash of recognizers and he has no idea what any of that syntax means. There is no point to this anyway --- it is just an effort to make Forth-200x source-code look pretty --- this doesn't help people to write programs though.
> 
> Forth-200x has become bloated with nonsense, and recognizers are just the latest in this trend. There are too many people making contributions to Forth-200x who either have never programmed in Forth or just program in Forth as a hobby --- this is why we have an effort to make the language pretty --- but nobody is concerned about making the language useful.

So, how is your criticism of Gerard's idea any different from my criticism of your beloved "recognizer" idea?

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

#48755 — Dealing with multiple recognizers (was: RfD: new double syntax)

hughaguilar96@gmail.com writes:
>On Sunday, July 3, 2016 at 7:39:01 AM UTC-7, Anton Ertl wrote:
>> Gerard Sontag <gerardsontag@gmail.com> writes:
>> >Hello from an unexperience reader,
>> >Why not create a new VARIABLE (name TBD) which will contain the preferre=
>d c=3D
>> >har indicating double.
...
>So, how is your criticism of Gerard's idea any different from my criticism =
>of your beloved "recognizer" idea?

I don't see much in common between my criticism of TBD (even if it is
not meant as a real name, it's a better handle than "Gerard's idea")
and your criticism of recognizers, so let me answer a different
question:

Would not user-defined recognizers have the same problems that BASE or
TBD have?

1) User-defined recognizers propose not just one variable, that
contains the current recognizer, and then you put in a different one.
If they did, then yes, the same problems would be there.  But for that
reason the proposal proposes a recognizer stack, that contains
multiple recognizers, similar to the search order.

2) Ideally, recognizers recognize disjoint sets of strings, or
alternatively, are designed to work together.  Of course, for
independently developed recognizers there is no guarantee of that they
don't overlap, but the programmer combining these recognizers can then
determine the priority by arranging them appropriately in the
recognizer stack; as a last resort, have some recognizer be first in
one file, and another recognizer be first in another file, but that
would be a short-term solution that should be resolved soon (e.g., by
adding an alternative non-conflicting syntax for at least one of the
recognizers).

I expect that the number of recognizers in general use will be
limited, and the authors will be keen on not treading on each others
toes; of course, I expect that there will be some people that do their
own thing and expect the world to revolve around them, but I don't
expect that recognizers that significantly conflict with other popular
recognizers to become widely used.

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

#48759 — Re: Dealing with multiple recognizers (was: RfD: new double syntax)

On Sunday, July 3, 2016 at 8:35:27 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >On Sunday, July 3, 2016 at 7:39:01 AM UTC-7, Anton Ertl wrote:
> >> Gerard Sontag <gerardsontag@gmail.com> writes:
> >> >Hello from an unexperience reader,
> >> >Why not create a new VARIABLE (name TBD) which will contain the preferre=
> >d c=3D
> >> >har indicating double.
> ...
> >So, how is your criticism of Gerard's idea any different from my criticism =
> >of your beloved "recognizer" idea?
> 
> I don't see much in common between my criticism of TBD (even if it is
> not meant as a real name, it's a better handle than "Gerard's idea")
> and your criticism of recognizers, so let me answer a different
> question:
> 
> Would not user-defined recognizers have the same problems that BASE or
> TBD have?
> 
> 1) User-defined recognizers propose not just one variable, that
> contains the current recognizer, and then you put in a different one.
> If they did, then yes, the same problems would be there.  But for that
> reason the proposal proposes a recognizer stack, that contains
> multiple recognizers, similar to the search order.
> 
> 2) Ideally, recognizers recognize disjoint sets of strings, or
> alternatively, are designed to work together.  Of course, for
> independently developed recognizers there is no guarantee of that they
> don't overlap, but the programmer combining these recognizers can then
> determine the priority by arranging them appropriately in the
> recognizer stack; as a last resort, have some recognizer be first in
> one file, and another recognizer be first in another file, but that
> would be a short-term solution that should be resolved soon (e.g., by
> adding an alternative non-conflicting syntax for at least one of the
> recognizers).
> 
> I expect that the number of recognizers in general use will be
> limited, and the authors will be keen on not treading on each others
> toes; of course, I expect that there will be some people that do their
> own thing and expect the world to revolve around them, but I don't
> expect that recognizers that significantly conflict with other popular
> recognizers to become widely used.
> 
> - anton

Lets assume that there are 5 recognizers in general use and all of them clash with each other in some way so the order that they are put on the recognizer-stack is significant. This means that there are 5! permutations, or 120 different versions of Forth-200x --- permutation is just another word for ambiguity --- ambiguity is the major problem in ANS-Forth, and you are making the problem worse rather than better.

You expect the authors to be "keen on not treading on each others toes"
--- really??? --- when has an expectation of common-sense among software users ever worked out well in the past?

We don't want to give people an opportunity to be creative in something so basic as the string>number function used in the outer-interpreter. Just decide on a reasonable definition of what a number is, and go with that. Save your creativity for something more useful (like writing programs!). 

My STR>NUM function in the string-stack.4th package was written primarily to be used in the outer-interpreter of Straight Forth. It seems like a reasonable definition of what a number is --- if people don't like it though, then it can be modified (maybe use the underscore rather than the comma, for example) --- I don't really care what gets done, so long as it is reasonable, and so long as the debate doesn't drag on for weeks (if Straight Forth is going to be ratified before the end of the year, the committee members can't debate for weeks on every triviality the comes up, otherwise the process will take years as has already happened in Forth-200x).

I said this:
On Wednesday, May 4, 2016 at 5:03:16 PM UTC-7, hughag...@gmail.com wrote: 
> Forth-200x has become bloated with nonsense, and recognizers are just the latest in this trend. There are too many people making contributions to Forth-200x who either have never programmed in Forth or just program in Forth as a hobby --- this is why we have an effort to make the language pretty --- but nobody is concerned about making the language useful. 

I expect that a lot of Forth-200x users (maybe all of them) will want to demonstrate their creativity. The obvious channel for this creative urge is to write their own recognizer(s) to change the syntax for Forth-200x --- then they can have their own special language! --- then they will try to convince the rest of the world to use their syntax. 

This is similar to how Albert v.d.Horst took an old copy of FIG Forth and upgraded it, then called it ciForth, then spent the rest of his life trying to convince the Forth community to use ciForth (and also claiming that because ciForth has a disassembler it is an AI program, which was somewhat of a baffling claim). Here is another even weirder example:
https://groups.google.com/forum/#!searchin/comp.lang.forth/heart$20forth%7Csort:date/comp.lang.forth/AtEWzxgrUEg/sngIhwHxPEwJ

People are always trying to create a meme --- their dream is to see their meme take off in popularity so people all over the world have the meme in their head although the people don't necessarily know the name of the genius who started the meme --- here is an example:
http://memegenerator.net/instance/53401411

It could be argued that my Straight Forth is yet another misguided attempt at starting a pointless meme. I don't think this is really true though. For one thing, I'm only doing this reluctantly because ANS-Forth and Forth-200x are complete failures --- my 5 principles represent what I think is needed in a desktop-computer Forth system, all of which ANS-Forth and Forth-200x fail at --- also, I know how to program in Forth already; I'm not like the typical Forth compiler-writer who has never written a Forth application program yet feels qualified to dive straight into compiler-writing and become an instant expert (Rod Pemberton, for example).

Down with creativity! Up with Straight Forth! (straight in the sense of traditional, and straight in the sense of minimalist)

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

#48794

On 7/3/2016 10:21 AM, Anton Ertl wrote:
> Gerard Sontag <gerardsontag@gmail.com> writes:
>> Hello from an unexperience reader,
>> Why not create a new VARIABLE (name TBD) which will contain the preferred c=
>> har indicating double.
>
> A bad idea, like BASE.  You then have a bunch of programs written in
> mutually incompatible Forth dialects, where you have to set TBD at
> each file start and/or save and restore it before any INCLUDE and/or
> at the start and end of every file.  And because there will be no
> common convention, programmers will leave all this complicated stuff
> away in the name of simplicity (except maybe setting TBD to a
> non-default value, but they will certainly leave setting it to the
> default value away), so combining independently developed libraries
> will become even more problematic than it is now.
>
> Of course, like many bad ideas, this one has been implemented in a
> Forth system, under the name DP-CHAR, not TBD.  DP-CHAR is a little
> better then TBD by being able to hold up to four characters, but AFAIK
> there is no word to make joining another character to the set easy.
>
>> The point character would be the default value letting old programs running=
>> .
>
> Which will do nothing to solve the problem that this RfD attacks.

The value of TBD doesn't need to be set before loading the file, it 
should be set in the beginning of the file *before* using an alternative 
syntax to using the decimal point.

-- 

Rick C

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

#48805

Le mardi 5 juillet 2016 07:12:52 UTC+2, rickman a écrit :
> On 7/3/2016 10:21 AM, Anton Ertl wrote:

> >
> > Which will do nothing to solve the problem that this RfD attacks.
> 
> The value of TBD doesn't need to be set before loading the file, it 
> should be set in the beginning of the file *before* using an alternative 
> syntax to using the decimal point.
> 
> -- 
> 
> Rick C

Yes but when you fire your system you need to be able to recognize :o) a double.

Gérard

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

#48806

On 7/5/2016 10:56 AM, Gerard Sontag wrote:
> Le mardi 5 juillet 2016 07:12:52 UTC+2, rickman a écrit :
>> On 7/3/2016 10:21 AM, Anton Ertl wrote:
>
>>>
>>> Which will do nothing to solve the problem that this RfD attacks.
>>
>> The value of TBD doesn't need to be set before loading the file, it
>> should be set in the beginning of the file *before* using an alternative
>> syntax to using the decimal point.
>>
>> --
>>
>> Rick C
>
> Yes but when you fire your system you need to be able to recognize :o) a double.

"Fire your system"???   The recognition can be set by the file being 
loaded.  It doesn't need to be set in the booting of the Forth.

-- 

Rick C

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

#48754

On Sunday, 3 July 2016 14:58:26 UTC+1, Gerard Sontag  wrote:
> Hello from an unexperience reader,
> Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double.
> The point character would be the default value letting old programs running.
> For those who want to use another char it will be set at the beginning.
> Candidates (for me) are underscore, caret and backslash
> 
> Gérard

Long ago, before there was Floating point numbers in Forth...
 
A number could be single or double, and recognized in any base up to 39 digits were 0-9 and A-Z (case insensitive) if needed. That meant you could do thingsd like change BASE temporarily and interpret short letter codes as numbers. You still can. 

Number conversion starts with a double number 0. It reads character by character and if it is a valid digit then it multiplies the seed number by the value in BASE and adds the new digit to it. If all the characters are valid, then you convert the final double number to a single, and maybe check for overflow. 

That's all there was to it, apart from checking first for a sign and possibly negating at the end. Some Forths expanded that by noting where conversion stopped on a non-digit and taking special action accordingly. That allowed them to recognise such things as dates and fixed point numbers. Others just treated any number with non-digit anywhere in it as a double number. It was a mess, and we're only now (maybe) getting a way to do such things sensibly and portably with Recognizers - maybe. 

The only thing we could do to standardise was to take a format for double numbers that worked for everyone - a string of valid digits followed by a single non-digit. Very easy to implement - stop at the first non-digit, and there's your double number. It wouldn't at all surprise me if some Forths don't even check if it is a . or the last character of the string.

Nowadays we can prefix any double to declare its base, and that is good practice IMHO. I've never seen a case of a double number in an unusual base, and not something that should be in the core number conversion routine.

There is no reason to treat a number with a trailing decimal point and no following digits as floating point; 45766.0 is always clearer than 45766. , but if it is important to catch the latter as a error, then by all means give your system a switch that allows it to do so. When the switch is active all double numbers have to be preceded by their base prefix but that, as I have said, is good practice anyway. The code that it can interpret is still Standard Code, and it only needs to be active when interpreting user input. Like Gorth's COMPILE-ONLY it's something for the individual systems implementer, not something that should be in the Standard. Whether or not it is important enough to render un-prefixed double numbers obsolescent, only time will decide. 

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

#48761

On 7/3/2016 8:58 AM, Gerard Sontag wrote:
> Hello from an unexperience reader,
> Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double.
> The point character would be the default value letting old programs running.
> For those who want to use another char it will be set at the beginning.
> Candidates (for me) are underscore, caret and backslash
>
> Gérard
>
There is a programming concept called concurrency, it allows a set of 
code to be simultaneously be executed by separate threads, a very useful 
thing. The gist of it does not allow for fixed variables to determine 
the state of code, as two copies of the code running at the same time 
might need different set of states. State is generally a bad idea as it 
prevents concurrency, it can be done by each instance having it's own 
state data, but that is messy in Forth.

Since Forth use of data is mostly stack based it should be a perfect 
vehicle to allow concurrency but fixed state variables ruin it, things 
like base created problems. That is also why C creates stack frames so 
each function can have it's own private variables and state and not mess 
up concurrency.


-- 
Cecil - k5nwa

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

#48764

On 7/3/16 7:42 AM, Cecil Bayona wrote:
> On 7/3/2016 8:58 AM, Gerard Sontag wrote:
>> Hello from an unexperience reader,
>> Why not create a new VARIABLE (name TBD) which will contain the
>> preferred char indicating double.
>> The point character would be the default value letting old programs
>> running.
>> For those who want to use another char it will be set at the beginning.
>> Candidates (for me) are underscore, caret and backslash
>>
>> Gérard
>>
> There is a programming concept called concurrency, it allows a set of
> code to be simultaneously be executed by separate threads, a very useful
> thing. The gist of it does not allow for fixed variables to determine
> the state of code, as two copies of the code running at the same time
> might need different set of states. State is generally a bad idea as it
> prevents concurrency, it can be done by each instance having it's own
> state data, but that is messy in Forth.
>
> Since Forth use of data is mostly stack based it should be a perfect
> vehicle to allow concurrency but fixed state variables ruin it, things
> like base created problems. That is also why C creates stack frames so
> each function can have it's own private variables and state and not mess
> up concurrency.


AFAIK any Forths that support concurrency have "user variables" 
available for things that need to be used by shared code. BASE is always 
a user variable in such systems, along with various others.

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]

#48771

On Sunday, July 3, 2016 at 12:32:40 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/3/16 7:42 AM, Cecil Bayona wrote:
> > Since Forth use of data is mostly stack based it should be a perfect
> > vehicle to allow concurrency but fixed state variables ruin it, things
> > like base created problems. That is also why C creates stack frames so
> > each function can have it's own private variables and state and not mess
> > up concurrency.
> 
> AFAIK any Forths that support concurrency have "user variables" 
> available for things that need to be used by shared code. BASE is always 
> a user variable in such systems, along with various others.

ANS-Forth is cripple-ware. Most of the good stuff in Forth, that had been common practice for decades, was banned in ANS-Forth (user variables in this example). You do quite a lot of boasting about Charles Moore's genius, as if you have a monopoly on it, but in practice you banned most of his good ideas from ANS-Forth and only kept his bad ideas. Like most geniuses, he had both good ideas and bad ideas, so it is foolish to religiously adhere to every idea that he had --- you are pretending to be Moses bringing Charles Moore's Forth down from Mt. Sinai written on stone tablets --- but you are dumb as a box of rocks yourself, so you don't know the difference between good ideas and bad ideas, or you are evil so you purposely ban the good ideas from ANS-Forth so they can become corporate proprietary code.

The purpose of crippling ANS-Forth was to prevent the common Forth programmers from writing useful programs in ANS-Forth (in this case, programs that use concurrency). You purposely crippled ANS-Forth so that Forth programmers who want (actually need) the good features of Forth have to pay for a commercial Forth compiler --- OTOH, if anybody else writes a Forth compiler with the good features, you and the rest of the committee howl that their compiler is not ANS-Forth compliant and isn't really Forth at all --- that pretty much kills the sales of their compiler, as all the potential customers say: "Well, I don't want to commit to a non-standard compiler because then if they go out of business I won't be able to port my program to another compiler." The irony, of course, is that ANS-Forth programs can't be ported between ANS-Forth compilers anyway, because every ANS-Forth compiler has a different take on the many ambiguous aspects of ANS-Forth.

The end result is that there is effectively no Standard Forth at all. Everybody who writes a Forth program that does anything useful has to abandon ANS-Forth on the first day of the project. How is this situation any different from the situation we would have if ANS-Forth had not been ratified? Well, the big difference is that if ANS-Forth had not been ratified then a Forth Standard that made sense would have arisen as a grass-roots project among the Forth community --- for the most part, the only effect that ANS-Forth has had is to prevent a Forth Standard that makes sense from arising --- this continues to be the effect of Forth-200x today, two decades later.

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

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

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

csiph-web