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

RfD: new double syntax

Started by	anton@mips.complang.tuwien.ac.at (Anton Ertl)
First post	2016-07-01 17:18 +0000
Last post	2016-07-03 22:00 +0100
Articles	20 on this page of 93 — 23 participants

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

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

#48647 — RfD: new double syntax

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-07-01 17:18 +0000
Subject	RfD: new double syntax
Message-ID	<2016Jul1.191836@mips.complang.tuwien.ac.at>

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.

This is just one possible syntax, so if you absolutely cannot live
with it, I am happy to go for a different one that everybody can live
with.  But I don't want a bike-shedding discussion, so "I find <other
syntax> more pleasing" or "How about <other syntax>" is not a good
argument; a conflict of the proposed syntax with existing practice
would be a good argument, though.

The further steps would be to make the new syntax standard in the next
standard (N), and make the "1." syntax obsolescent.  Then
de-standardize "1."  in standard N+1.  If we then want to standardize
"1." as FP number, either have one revision cooldown period for this
syntax and standardize "1." as floating-point value in N+2, or already
in N+1 without cooldown period.  Yes, it takes long, that's why I want
to get started.

Proposal
--------

In "8.3.1 Text interpreter input number conversion", replace

|When the text interpreter processes a number, except a <cnum>, that is
|immediately followed by a decimal point and is not found as a
|definition name, the text interpreter shall convert it to a
|double-cell number.

with

|When the text interpreter processes a number, except a <cnum>, that is
|immediately preceded by an asterisk or (obsolescent) immediately
|followed by a decimal point, and is not found as a definition name,
|the text interpreter shall convert it to a double-cell number.


Typical usage
-------------

*-1
*$f
*#-1


Reference implementation
------------------------

When we get recognizers ...:-)

Test cases
----------

T{ *#-1 -- -1 -1 }T
T{ *1 -- 1 0 }T
T{ *$ff -- 255 0 }T

Experience
----------

None.

- 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] | [next] | [standalone]

#48650

From	hughaguilar96@gmail.com
Date	2016-07-01 11:45 -0700
Message-ID	<d3d6ccba-4c4c-4cf1-8439-45a79ce0d05d@googlegroups.com>
In reply to	#48647

On Friday, July 1, 2016 at 10:26:50 AM UTC-7, Anton Ertl wrote:
> 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.

Forth-200x is mandated to be 100% compatible with ANS-Forth. Forth-200x has no real purpose except to make ANS-Forth seem more important than it is. You can not change something as fundamental as the syntax for numbers in the source-code --- this will cause all ANS-Forth programs that have ever been written to fail to compile under Forth-200x --- Elizabeth Rather appointed all of the Forth-200x committee members including yourself, and if you make SwiftForth code non-standard she will fire you.

> Solution
> --------

We need a new Standard (Straight Forth) that is incompatible with ANS-Forth and that is written by programmers rather than a Forth Inc. sales-person.

In my string-stack.4th package, I wrote STR>NUM primarily so that it could be used in the outer-interpreter of Straight Forth. This is the documentation:

\ STR>INT converts strings to integers, either singles and doubles.
\ An integer is a string of digits. There may be commas throughout.
\ An integer may have a $ # or % at the front, signifying that it is hexadecimal, decimal or binary. If none of these are present, then BASE is used.
\ An integer may have a + or - at the front (after the base signifier if there is one), signifying non-negative or negative, but otherwise it is non-negative.
\ A comma at the beginning (after the sign signifier if there is one) signifies that the integer is a double, but otherwise it is a single.

\ These are valid integers:
\ $-,123,456        double: -123456 hexadecimal
\ -,123,456         double: -123456
\ ,123,456          double: 123456
\ 123,456           single: 123456

\ STR>FLT converts strings to floats.
\ A float is a string of digits. There may be commas throughout. All floats are in decimal.
\ A comma in the front is legal but should not be used as STR>NUM will interpret this as an invalid double.
\ There must be either a decimal-point or an exponent-signifier (either 'E' or 'e') or both.
\ If there is a decimal-point, there must be digits either before or after or both.
\ The first digits are the integer part. The digits after the decimal-point, if there is a decimal-point, are the fraction part.
\ The digits after the exponent-signifier, if there is an exponent-signifier, are the exponent part (scientific notation).
\ If there is an exponent-signifier, there must be digits after it.
\ An exponent may have a + or - at the front, signifying non-negative or negative, but otherwise it is non-negative.

\ STR>NUM converts strings to either integers or floats.

\ These are valid floats:
\ -123,456.78       float: -123456.78
\ -123,456.78E4     float: -1234567800
\ -123,456.78E-4    float: -12.345678
\ 123E4             float: 1230000

We had this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/EuroForth$202016/comp.lang.forth/D0PmblPgthM/iyZvwPgoDwAJ

Here 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.
> 
> I said earlier that I would be the "chief" and I would appoint the committee members (similar to how Elizabeth Rather appoints the committee members for Forth-200x). I'm not going to be like Leon Wagner though and tell everybody exactly what to believe, give them assignments, and write the specs for them (basically, treat them like code-monkeys). I just want to appoint the members so I can weed out people like Alex McDonald who claimed to "do standards for a living" (whatever the hell that means) and who knew very little about Forth. People can do whatever they want, so long as they adhere to the basic principles:
> 
> 1.) Minimalism. All that cruft in ANS-Forth will be discarded (for example: DO loops will go). I would expect the language to be less than half the size of ANS-Forth. As for the extension code-libraries, they will make the language bigger, but they are optional. They are containers (my list.4th and association.4th) or they are associated with a particular data-type (my string-stack.4th). The emphasis here should be on usefulness --- I was impressed by how Factor used "sequences" as a standard data-type, and this was my inspiration for list.4th --- also, almost all programs for desktop-computers are going to use strings, so having a standard library such as string-stack.4th is going to make the programs easy to read, rather than everybody doing something different in every program.
> 
> 2.) Behavior. The focus should be on standardizing behavior rather than implementation. One of the problems with ANS-Forth was that it standardized implementation. For example, ANS-Forth assumes that the >R data and the DO loops use the same stack, so they were standardizing on the PDP-11 implementation that had to do this because of a shortage of registers. Quite a lot of ANS-Forth assumes that the target processor is a PDP-11, apparently because that is the only processor that Elizabeth Rather is familiar with.
> 
> 3.) Quotations. My system with the fat-xt will be used to allow quotations to access the parent function's local variables. This is trivial to implement! This is the foundation to writing general-purpose data-structures --- I really see this as bring Forth into the 21st century --- make it comparable to the other desktop-computer language such as Lisp --- unlike Lisp though, we will not have garbage-collection or tagged data (we will not have Dynamic-OOP). The emphasis will still be on speed, and Dynamic-OOP is a dog, so leave that to the script kiddies.
> 
> 4.) Numerical. The 64-bit cell with the Fixed or Float data-type is fundamental to the language. I think this makes the language much simpler than ANS-Forth where integers and floats are distinct (so, this fits in with the minimalism idea). The "killer app" is CAM, but most machinists have experience primarily with using pocket calculators for figuring out gcode, and pocket calculators don't consider integers and floats to be distinct data-types. Also, it is important to define what the precision of the numbers is in the standard so the programmer knows what the results of numerical calculations are going to be and can expect the same results on every compliant compiler (so long as he sticks with either the Fixed or Float version, as they give different results from each other). I originally was only going to have the Fixed version, but Ilya Vasilyev convinced me to have a Float version also and to make them compatible with each other (except for a slight difference in the numeric results in some cases). This was here:
> https://groups.google.com/forum/#!searchin/comp.lang.forth/ilya%7Csort:date/comp.lang.forth/R7K3FWXnyKE/0_LJ13ZfBQAJ
> 
> 5.) Cross-Compilation. The compiler should have all the necessary features for writing a cross-compiler. This is actually pretty easy --- it is amazing that ANS-Forth failed at such a simple task (I'm highly suspicious that ANS-Forth was purposely sabotaged to make cross-compilation difficult in order to prevent common users from writing a cross-compiler in competition with Forth Inc. and MPE who make most of their money selling vendor-specific cross-compilers) --- I know how to write a cross-compiler, so I will make sure that this is supported.
> 
> These are the 5 principles of Straight-Forth. Who disagrees with any of these principles? Which ones? Why?
> 
> Note that LFTforth is for micro-controllers and would have different principles that it is based on --- that is really Raimond's thing, not mine.

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

#48651

From	rickman <gnuarm@gmail.com>
Date	2016-07-01 14:46 -0400
Message-ID	<nl6dqp$qkk$2@dont-email.me>
In reply to	#48650

On 7/1/2016 2:45 PM, hughaguilar96@gmail.com wrote:
> On Friday, July 1, 2016 at 10:26:50 AM UTC-7, Anton Ertl wrote:
>> 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.
>
> Forth-200x is mandated to be 100% compatible with ANS-Forth. Forth-200x has no real purpose except to make ANS-Forth seem more important than it is. You can not change something as fundamental as the syntax for numbers in the source-code --- this will cause all ANS-Forth programs that have ever been written to fail to compile under Forth-200x --- Elizabeth Rather appointed all of the Forth-200x committee members including yourself, and if you make SwiftForth code non-standard she will fire you.
>
>> Solution
>> --------
>
> We need a new Standard (Straight Forth) that is incompatible with ANS-Forth and that is written by programmers rather than a Forth Inc. sales-person.
>
> In my string-stack.4th package, I wrote STR>NUM primarily so that it could be used in the outer-interpreter of Straight Forth. This is the documentation:
>
> \ STR>INT converts strings to integers, either singles and doubles.
> \ An integer is a string of digits. There may be commas throughout.
> \ An integer may have a $ # or % at the front, signifying that it is hexadecimal, decimal or binary. If none of these are present, then BASE is used.
> \ An integer may have a + or - at the front (after the base signifier if there is one), signifying non-negative or negative, but otherwise it is non-negative.
> \ A comma at the beginning (after the sign signifier if there is one) signifies that the integer is a double, but otherwise it is a single.
>
> \ These are valid integers:
> \ $-,123,456        double: -123456 hexadecimal
> \ -,123,456         double: -123456
> \ ,123,456          double: 123456
> \ 123,456           single: 123456
>
> \ STR>FLT converts strings to floats.
> \ A float is a string of digits. There may be commas throughout. All floats are in decimal.
> \ A comma in the front is legal but should not be used as STR>NUM will interpret this as an invalid double.
> \ There must be either a decimal-point or an exponent-signifier (either 'E' or 'e') or both.
> \ If there is a decimal-point, there must be digits either before or after or both.
> \ The first digits are the integer part. The digits after the decimal-point, if there is a decimal-point, are the fraction part.
> \ The digits after the exponent-signifier, if there is an exponent-signifier, are the exponent part (scientific notation).
> \ If there is an exponent-signifier, there must be digits after it.
> \ An exponent may have a + or - at the front, signifying non-negative or negative, but otherwise it is non-negative.
>
> \ STR>NUM converts strings to either integers or floats.
>
> \ These are valid floats:
> \ -123,456.78       float: -123456.78
> \ -123,456.78E4     float: -1234567800
> \ -123,456.78E-4    float: -12.345678
> \ 123E4             float: 1230000
>
> We had this thread:
> https://groups.google.com/forum/#!searchin/comp.lang.forth/EuroForth$202016/comp.lang.forth/D0PmblPgthM/iyZvwPgoDwAJ
>
> Here 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.
>>
>> I said earlier that I would be the "chief" and I would appoint the committee members (similar to how Elizabeth Rather appoints the committee members for Forth-200x). I'm not going to be like Leon Wagner though and tell everybody exactly what to believe, give them assignments, and write the specs for them (basically, treat them like code-monkeys). I just want to appoint the members so I can weed out people like Alex McDonald who claimed to "do standards for a living" (whatever the hell that means) and who knew very little about Forth. People can do whatever they want, so long as they adhere to the basic principles:
>>
>> 1.) Minimalism. All that cruft in ANS-Forth will be discarded (for example: DO loops will go). I would expect the language to be less than half the size of ANS-Forth. As for the extension code-libraries, they will make the language bigger, but they are optional. They are containers (my list.4th and association.4th) or they are associated with a particular data-type (my string-stack.4th). The emphasis here should be on usefulness --- I was impressed by how Factor used "sequences" as a standard data-type, and this was my inspiration for list.4th --- also, almost all programs for desktop-computers are going to use strings, so having a standard library such as string-stack.4th is going to make the programs easy to read, rather than everybody doing something different in every program.
>>
>> 2.) Behavior. The focus should be on standardizing behavior rather than implementation. One of the problems with ANS-Forth was that it standardized implementation. For example, ANS-Forth assumes that the >R data and the DO loops use the same stack, so they were standardizing on the PDP-11 implementation that had to do this because of a shortage of registers. Quite a lot of ANS-Forth assumes that the target processor is a PDP-11, apparently because that is the only processor that Elizabeth Rather is familiar with.
>>
>> 3.) Quotations. My system with the fat-xt will be used to allow quotations to access the parent function's local variables. This is trivial to implement! This is the foundation to writing general-purpose data-structures --- I really see this as bring Forth into the 21st century --- make it comparable to the other desktop-computer language such as Lisp --- unlike Lisp though, we will not have garbage-collection or tagged data (we will not have Dynamic-OOP). The emphasis will still be on speed, and Dynamic-OOP is a dog, so leave that to the script kiddies.
>>
>> 4.) Numerical. The 64-bit cell with the Fixed or Float data-type is fundamental to the language. I think this makes the language much simpler than ANS-Forth where integers and floats are distinct (so, this fits in with the minimalism idea). The "killer app" is CAM, but most machinists have experience primarily with using pocket calculators for figuring out gcode, and pocket calculators don't consider integers and floats to be distinct data-types. Also, it is important to define what the precision of the numbers is in the standard so the programmer knows what the results of numerical calculations are going to be and can expect the same results on every compliant compiler (so long as he sticks with either the Fixed or Float version, as they give different results from each other). I originally was only going to have the Fixed version, but Ilya Vasilyev convinced me to have a Float version also and to make them compatible with each other (except for a slight difference in the numeric results in some cases). This was here:
>> https://groups.google.com/forum/#!searchin/comp.lang.forth/ilya%7Csort:date/comp.lang.forth/R7K3FWXnyKE/0_LJ13ZfBQAJ
>>
>> 5.) Cross-Compilation. The compiler should have all the necessary features for writing a cross-compiler. This is actually pretty easy --- it is amazing that ANS-Forth failed at such a simple task (I'm highly suspicious that ANS-Forth was purposely sabotaged to make cross-compilation difficult in order to prevent common users from writing a cross-compiler in competition with Forth Inc. and MPE who make most of their money selling vendor-specific cross-compilers) --- I know how to write a cross-compiler, so I will make sure that this is supported.
>>
>> These are the 5 principles of Straight-Forth. Who disagrees with any of these principles? Which ones? Why?
>>
>> Note that LFTforth is for micro-controllers and would have different principles that it is based on --- that is really Raimond's thing, not mine.

And now we see clearly why Hugh is not part of the standards process...

-- 

Rick C

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

#48652

From	Julian Fondren <julian.fondren@gmail.com>
Date	2016-07-01 11:47 -0700
Message-ID	<98422a5e-4421-4d8f-83e0-760ba7e90c74@googlegroups.com>
In reply to	#48647

On Friday, July 1, 2016 at 12:26:50 PM UTC-5, Anton Ertl wrote:
> Problem
> -------
> 
> People coming from other languages expect "1." to be a floating-point
> number. 
>

Ruby:

  $ irb
  irb(main):001:0> 1
  => 1
  irb(main):002:0> 1.0
  => 1.0
  irb(main):003:0> 1.
  irb(main):004:0* 

There's no "=>" and result output at this point because Ruby doesn't
consider 1. to be a complete expression.  Continued:

  irb(main):004:0* to_f
  => 1.0

The input was taken to be "1.to_f", a method invocation on a Fixnum.

> this
> makes Forth harder to teach and damages the reputation among
> newcomers: First when they trip across this trap,

To trip, you must first have forward movement.  When someone thinks
they've learned Forth, starts writing a program, and then runs into a
confusing error -- that's a "trip".  Every few years I trip over Perl's
scalar/list/void context mechanic.  Floating point syntax is something
that you can only get wrong before you know the language well enough to
be doing much beyond flipping to the next page of a tutorial.

> and further when they hear about the reason for this behaviour.

Forth has support for a type that most other languages don't have
(scripting languages even tend to have only a single numerical type),
and it supports them in a way that other languages don't, when those
languages do have something similar.  Other languages try to behave as
if computers have variable-width registers; Forth exposes what's really
going on.  Neat!

(Please don't rebut 'variable-width registers' with AX EAX et al.)

If you have some demoralizing historical explanation, why do you have
it?  There's a time for historical footnotes and there's a time to
simply describe circumstances as they are right now.

In Ruby you must write 1.0; you can't just write 1. -- because that's
something else.

In Forth you must write 1e; you can't just write 1. -- because that's
something else.

Programming languages vary enormously by syntax, especially in the
details, even when the languages overall have a very similar appearance.
Someone coming from other languages can be expected to know that.
Semicolons and whitespace are famous, but those are just the start.

System    Doubles   Floats
CURRENT     1.        1e
PROPOSED    *1        1e
FUTURE      *1        1.

No matter which system you have, Forth is still a new language with new
syntax which must be understood before it can be used even with enough
energy for the user to trip over anything.  All that changes when you
move from CURRENT to some other system is that Forth is then less
compatible with itself.

As annoying as porting Forth can be (I had a lot going on, but it might
*not* be a total coincidence that I put that webserver aside when I was
working on getting other systems to run it), one advantage that it has
over many other languages is that its standardization and quality
implementations mean that Forth code 'rots' very, very slowly.  There's
no Python2/Python3 division.  There isn't PHP's list of breaking changes
and new reserved words that come with every release.  There isn't
Clojure having strict semantics one day and then lazy semantics the
next.  Software written in such languages is far more annoying to
maintain and yet the churn rarely goes as far as changing the syntax of
basic numerical types.

Suppose that you had TRADITIONAL-NUMBERS and NATURAL-NUMBERS as words
that changed the recognizer stack between the CURRENT and SYSTEM numbers
from above, respectively.  This would be annoying for all the same
reasons BASE is today.  Still, isn't it better than simply breaking all
traditionally-written code?  And wouldn't every system that tries to
break traditionally-written code as you propose end up *also* writing in
a TRADITIONAL-NUMBERS word in somewhere, that may itself vary from
system to system as with WARNING vs. WARNINGS today?  The alternative
you try to avoid in the standard, you get anyway in implementations.

I see only harm coming from adoption of this proposal.  I challenge
anyone to attempt to thoroughly list the surprising differences between
Forth and most languages today, and then to sort that list in any way
that results in this proposal standing out as especially appealing or
worthwhile.

-- Julian

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

#48705

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-07-02 14:54 +0000
Message-ID	<2016Jul2.165431@mips.complang.tuwien.ac.at>
In reply to	#48652

Julian Fondren <julian.fondren@gmail.com> writes:
>On Friday, July 1, 2016 at 12:26:50 PM UTC-5, Anton Ertl wrote:
>> Problem
>> -------
>> 
>> People coming from other languages expect "1." to be a floating-point
>> number. 
>>
>
>Ruby:
>
>  $ irb
>  irb(main):001:0> 1
>  => 1
>  irb(main):002:0> 1.0
>  => 1.0
>  irb(main):003:0> 1.
>  irb(main):004:0* 
>
>There's no "=>" and result output at this point because Ruby doesn't
>consider 1. to be a complete expression.

If all languages worked like this, "1." would not be a problem.
However, many languages consider "1." as a floating point number, and
that's where the expectations of many Forth newcomers are formed.
E.g.:

Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1.
1.0

GPL Ghostscript 9.06 (2012-08-08)
Copyright (C) 2012 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>1. =
1.0

>To trip, you must first have forward movement.  When someone thinks
>they've learned Forth, starts writing a program, and then runs into a
>confusing error -- that's a "trip".

That's pretty much what is happening here.

> Floating point syntax is something
>that you can only get wrong before you know the language well enough to
>be doing much beyond flipping to the next page of a tutorial.

Not everybody learns a language by flipping pages of a tutorial.

>If you have some demoralizing historical explanation, why do you have
>it?  There's a time for historical footnotes and there's a time to
>simply describe circumstances as they are right now.

When you describe what is there now without giving an explanation, the
language looks even worse than wehen you give the "demoralizing
historical explanation".

>In Ruby you must write 1.0; you can't just write 1. -- because that's
>something else.
>
>In Forth you must write 1e; you can't just write 1. -- because that's
>something else.

I don't know how well it turns out in Ruby (probably not very well),
but in your example at least one gets immediate feedback that
something is wrong, unlike with 1. in Forth.

Anyway, yes, other languages are not immune to stupid syntax, either;
an example is Edinburgh Prolog's clause syntax, especially because
that's a mistake that the original Marseille Prolog did not make.

>Programming languages vary enormously by syntax, especially in the
>details, even when the languages overall have a very similar appearance.
>Someone coming from other languages can be expected to know that.

There is not that much variation in floating-point syntax.  If a
language does not accept "1." as floating-point number, it certainly
does not accept it as something else.  Except Forth.

>System    Doubles   Floats
>CURRENT     1.        1e
>PROPOSED    *1        1e
>FUTURE      *1        1.
[...]
>Suppose that you had TRADITIONAL-NUMBERS and NATURAL-NUMBERS as words
>that changed the recognizer stack between the CURRENT and SYSTEM numbers
>from above, respectively.  This would be annoying for all the same
>reasons BASE is today.  Still, isn't it better than simply breaking all
>traditionally-written code?

There are certainly transition strategies for existing code:

If you want to keep the code as-is, you could have something like
TRADITIONAL-NUMBERS (an environmental query would be better, because
it also works on old systems).  A way to switch back to the PROPOSED
syntax would indeed introduce the problems that BASE gives us now, so
I would not recommend adding that.

If you want to change the source code to comply with the PROPOSED
syntax, run it through a converter.

>And wouldn't every system that tries to
>break traditionally-written code as you propose end up *also* writing in
>a TRADITIONAL-NUMBERS word in somewhere, that may itself vary from
>system to system as with WARNING vs. WARNINGS today?

If we want a standard way to re-enable the "1.-is-a-double" syntax, we
can certainly standardize that.  Anybody who does that hopefully knows
what they are doing, but the newcomers would get an error from
1. instead of an unexpected, seemingly successful result.

>I see only harm coming from adoption of this proposal.  I challenge
>anyone to attempt to thoroughly list the surprising differences between
>Forth and most languages today, and then to sort that list in any way
>that results in this proposal standing out as especially appealing or
>worthwhile.

The "1. is a double" is certainly the one that sticks out in my
teaching experience as being both nasty (because it's a silent
surprise), and not at all instructive in any way.  For comparison,
another frequent mistake is

."hello, world"

but it results in an error message and it illustrates that ." is just
a word, not some build-in syntax.

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

#48653

From	mhx@iae.nl
Date	2016-07-01 11:48 -0700
Message-ID	<2eec6f29-5981-4475-a054-03d29518ca22@googlegroups.com>
In reply to	#48647

On Friday, July 1, 2016 at 7:26:50 PM UTC+2, Anton Ertl wrote:
> Problem
[..] 
> Experience
> ----------
> 
> None.

This is what Forth people think about previous
"improvements" of the obsolete double number syntax:

SwiftForth i386-Win32 3.6.3 29-Jun-2016
3.2  ok
.s
32 0 <-Top  ok
d. 32  ok
0.32  ok
d. 32  ok
.32  ok
d. 32 
3,2  ok
d. 32  ok
3:2 d. 32  ok

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
3.2  ok
.s <2> 32 0  ok

-marcel

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

#48700

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-07-02 14:52 +0000
Message-ID	<2016Jul2.165205@mips.complang.tuwien.ac.at>
In reply to	#48653

mhx@iae.nl writes:
>On Friday, July 1, 2016 at 7:26:50 PM UTC+2, Anton Ertl wrote:
>> Problem
>[..] 
>> Experience
>> ----------
>> 
>> None.
>
>This is what Forth people think about previous
>"improvements" of the obsolete double number syntax:
>
>SwiftForth i386-Win32 3.6.3 29-Jun-2016
>3.2  ok
>.s
>32 0 <-Top  ok
>d. 32  ok
>0.32  ok
>d. 32  ok
>.32  ok
>d. 32 
>3,2  ok
>d. 32  ok
>3:2 d. 32  ok
>
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>3.2  ok
>.s <2> 32 0  ok

Your point being?

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

#48657

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-07-01 09:10 -1000
Message-ID	<zb6dncZoGo64XevKnZ2dnUU7-IXNnZ2d@supernews.com>
In reply to	#48647

On 7/1/16 7:18 AM, Anton Ertl wrote:
> 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.
>
> This is just one possible syntax, so if you absolutely cannot live
> with it, I am happy to go for a different one that everybody can live
> with.  But I don't want a bike-shedding discussion, so "I find <other
> syntax> more pleasing" or "How about <other syntax>" is not a good
> argument; a conflict of the proposed syntax with existing practice
> would be a good argument, though.
>
> The further steps would be to make the new syntax standard in the next
> standard (N), and make the "1." syntax obsolescent.  Then
> de-standardize "1."  in standard N+1.  If we then want to standardize
> "1." as FP number, either have one revision cooldown period for this
> syntax and standardize "1." as floating-point value in N+2, or already
> in N+1 without cooldown period.  Yes, it takes long, that's why I want
> to get started.
>
> Proposal
> --------
>
> In "8.3.1 Text interpreter input number conversion", replace
>
> |When the text interpreter processes a number, except a <cnum>, that is
> |immediately followed by a decimal point and is not found as a
> |definition name, the text interpreter shall convert it to a
> |double-cell number.
>
> with
>
> |When the text interpreter processes a number, except a <cnum>, that is
> |immediately preceded by an asterisk or (obsolescent) immediately
> |followed by a decimal point, and is not found as a definition name,
> |the text interpreter shall convert it to a double-cell number.
>
>
> Typical usage
> -------------
>
> *-1
> *$f
> *#-1
>
>
> Reference implementation
> ------------------------
>
> When we get recognizers ...:-)
>
> Test cases
> ----------
>
> T{ *#-1 -- -1 -1 }T
> T{ *1 -- 1 0 }T
> T{ *$ff -- 255 0 }T
>
> Experience
> ----------
>
> None.
>
> - anton
>

One of the cultural differences between Forth and other languages,
dating back to its invention, is that most high-level languages were
developed on large computers and expect floating point numbers. The
early minicomputers for which Forth was designed lacked hardware 
floating point, and Chuck's genius led to operators such as */ and /MOD 
and their relatives. These helped make scaled fixed-point arithmetic a 
fast and accurate computational alternative for complicated 
trigonometry, FFTs, and other computational requirements of motion 
control, image processing, and other early application areas in which 
Forth excelled. Even today, most micro-controllers used in embedded 
applications, still a major market for Forth, lack hardware FP, and few 
embedded applications require it. It would be very uncomfortable to 
burden these programs with notational requirements such as the asterisk 
that are not meaningful to most programmers and users.

The Forth94 TC struggled with this issue, and the trailing decimal point 
was the best compromise they could come up with. I realize it isn't 
ideal, and can present awkward surprises for programmers for whom
floating point is the expected norm. I don't know what would constitute
an ideal solution, but suggest that perhaps a qualifying condition such
as the presence of the Floating Point wordset be used.

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]

#48671

From	hughaguilar96@gmail.com
Date	2016-07-01 19:10 -0700
Message-ID	<1900b1e9-1ea7-4c40-8f96-14136c863408@googlegroups.com>
In reply to	#48657

On Friday, July 1, 2016 at 12:10:34 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/1/16 7:18 AM, Anton Ertl wrote:
> > 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.
> > ...
> 
> One of the cultural differences between Forth and other languages,
> dating back to its invention, is that most high-level languages were
> developed on large computers and expect floating point numbers. The
> early minicomputers for which Forth was designed lacked hardware 
> floating point, and Chuck's genius led to operators such as */ and /MOD 
> and their relatives. 

Elizabeth Rather has dedicated her life to holding Forth at the level of 1974 technology.

Note that nobody is arguing against */ and /MOD etc. --- everybody likes mixed-precision arithmetic, and that really was Charles Moore's genius --- what people are arguing against is ANS-Forth's goofy numbers in which 123.456 is not a floating-point number, but is a double-precision integer equal to 123,456 or 123456. or .123456 or 1,234.56 etc..

Anyway, Leon Wagner (Elizabeth Rather's employee) has already killed Anton's RfD. He says:
---------------------------------------------------------------------------
I have no problem with “1.” being a double (and not a float) nor do we receive complaints about it. ... I don’t see anything to be gained by doing this. (And the “other languages” argument isn’t a very strong one, IMO.)
---------------------------------------------------------------------------

Anton Ertl, you silly little boy! Don't you know that you can't make Forth-200x incompatible with ANS-Forth in any way? Now you have been publicly spanked by your boss! 

Well, look on the bright side --- your boss could have fired you from your job and replaced you with somebody more loyal --- you still have your job as chair-person of the Forth-200x committee, but you need to be more loyal in the future, so don't make any more brash attempts at raising Standard Forth above the level of 1974 technology!

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

#48682

From	"WJ" <w_a_x_man@yahoo.com>
Date	2016-07-02 06:23 +0000
Message-ID	<nl7mlm$joa$1@dont-email.me>
In reply to	#48671

hughaguilar96@gmail.com wrote:

> Anyway, Leon Wagner (Elizabeth Rather's employee) has
> already killed Anton's RfD. He says:
> ---------------------------------------------------------------------------
> I have no problem with "1." being a double (and not a
> float) nor do we receive complaints about it. ... I
> don't see anything to be gained by doing this. (And the
> "other languages" argument isn't a very strong one,
> IMO.)
> -------------------------------------------------------

People don't complain about it because they know that
neanderthal Leon with bash them on the head with his
club if they do.

"Other languages" have 2.0 as a float because that's
what people want, but Leon doesn't care about that.
He is content with his stone-age technology.

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

#48675

From	krishna.myneni@ccreweb.org
Date	2016-07-01 20:54 -0700
Message-ID	<740e597a-19ab-4f05-8f9b-6f03af9686ed@googlegroups.com>
In reply to	#48647

Anton Ertl wrote:
...
> In the long term, make "1." either non-standard or (even longer-term)  ...


Yes, I think we should deprecate the use of a trailing decimal point for the entry of double numbers, because it is such a different use than in other languages. On the other hand, I don't believe we should change the required notation for interpreting floating point numbers at all. Thus, unless "1." is a defined word, it should not be valid to the interpreter as either a double number or a floating point number. Such a change will also mitigate unexpected behavior by code, since use of the presently accepted double number entry with a trailing decimal point will trigger an error by the interpreter.

Sorry, I don't like the proposed notation because it puts an arithmetic operator (*) in front of the number.

Krishna

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

#48677

From	krishna.myneni@ccreweb.org
Date	2016-07-01 21:18 -0700
Message-ID	<b1e094f0-df60-4922-a4c4-f0629338d282@googlegroups.com>
In reply to	#48675

Krishna Myneni wrote:
> Sorry, I don't like the proposed notation because it puts an arithmetic operator (*) in front of the number. 

How about a trailing underscore for designating a double number, e.g.

  1_

?


KM

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

#48680

From	hughaguilar96@gmail.com
Date	2016-07-01 22:26 -0700
Message-ID	<e2b45774-711e-468b-9885-8f78af02ba58@googlegroups.com>
In reply to	#48677

On Friday, July 1, 2016 at 9:18:08 PM UTC-7, krishna...@ccreweb.org wrote:
> Krishna Myneni wrote:
> > Sorry, I don't like the proposed notation because it puts an arithmetic operator (*) in front of the number. 
> 
> How about a trailing underscore for designating a double number, e.g.
> 
>   1_
> 
> ?

I would be okay with that --- I could modify STR>NUM to do that instead of the leading comma indicating double-precision --- I agree that the leading asterisk was a bad idea because it looks like an arithmetic operator.

Make these suggestions in regard to Straight Forth --- it is pointless to make suggestions in regard to Forth-200x because nothing can ever be introduced into Forth-200x that will be incompatible with ANS-Forth --- Leon Wagner has already killed Anton's RfD.

Double numbers are an extension package in Straight Forth --- the cell size is 64-bit, so double numbers aren't going to be needed by very many programs --- it is possible that the double number extension will never get written because there is no interest.

Straight Forth is similar to Lua and other scripting languages in that it has only one type of number --- it has 64-bit fixed-point with an assumed unity of 2^32 in the Fixed version, or 64-bit IEEE-754 floats in the Float version --- most programs will run fine under either version, although occasionally you will have numeric programs that specify one version or the other.

I intend to start out with the Fixed version because modern computers are 64-bit, and the reduced range of the numbers shouldn't be a problem for most programs. The Float version may not get written at all because there is no interest. The most important applications are:
1.) cross-compilation of Forth to micro-controllers
2.) CAM (computer-aided-manufacture), which involves generating gcode for CNC machines
Both of these applications should work fine in the Fixed version. The Float version would be used for astronomy maybe, but since I'm not an astronomer this isn't a concern for me right away. The Float version might also be used for 32-bit x86 machines that have an x87 coprocessor because these can do IEEE-754 more efficiently than they can do 64-bit fixed.

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

#48716

From	"WJ" <w_a_x_man@yahoo.com>
Date	2016-07-02 22:32 +0000
Message-ID	<nl9fd3$flk$1@dont-email.me>
In reply to	#48680

hughaguilar96@gmail.com wrote:

> > How about a trailing underscore for designating a double number, e.g.
> > 
> >   1_
> > 
> > ?
> 
> I would be okay with that ---

OCaml uses a trailing L to indicate a 64-bit integer:

# 8_123_456_789L ;;
- : int64 = 8123456789L

Like Ruby, OCaml allows the user to insert underscores for
readability.

-- 
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

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

#48730

From	rickman <gnuarm@gmail.com>
Date	2016-07-03 01:16 -0400
Message-ID	<nla73s$9jl$1@dont-email.me>
In reply to	#48716

On 7/2/2016 6:32 PM, WJ wrote:
> hughaguilar96@gmail.com wrote:
>
>>> How about a trailing underscore for designating a double number, e.g.
>>>
>>>   1_
>>>
>>> ?
>>
>> I would be okay with that ---
>
> OCaml uses a trailing L to indicate a 64-bit integer:
>
> # 8_123_456_789L ;;
> - : int64 = 8123456789L
>
> Like Ruby, OCaml allows the user to insert underscores for
> readability.

The letter L is ok I suppose, but I have read that Forth supports using 
any letters of the alphabet for bases beyond 16.  Using the letter L at 
the end of a number to indicate double precision numbers prevents the 
use of bases beyond... well, some point.  Base 21 I think.  Not at all 
sure if this feature is used much or even at all.

-- 

Rick C

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

#48731

From	Ron Aaron <rambamist@gmail.com>
Date	2016-07-03 08:34 +0300
Message-ID	<nla854$bq4$1@dont-email.me>
In reply to	#48730


On 03/07/2016 08:16, rickman wrote:

> The letter L is ok I suppose, but I have read that Forth supports using
> any letters of the alphabet for bases beyond 16.  Using the letter L at
> the end of a number to indicate double precision numbers prevents the
> use of bases beyond... well, some point.  Base 21 I think.  Not at all
> sure if this feature is used much or even at all.

'base' is used.

Sample in 8th for random password generation using base-36 (ten digits
and 26 letters):

: rand-range \ low hi -- rand
	n:1+ over n:- rand n:abs
	swap n:mod n:+ ;

: base36 \ n -- s
	36 base
	swap >s
	swap base drop ;

: gen-pwd
	10000000000
	999999999999999
	rand-range
	base36 ;

"Password: " .
gen-pwd . cr bye

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

#48734

From	rickman <gnuarm@gmail.com>
Date	2016-07-03 03:00 -0400
Message-ID	<nlad5r$o3f$1@dont-email.me>
In reply to	#48731

On 7/3/2016 1:34 AM, Ron Aaron wrote:
>
>
> On 03/07/2016 08:16, rickman wrote:
>
>> The letter L is ok I suppose, but I have read that Forth supports using
>> any letters of the alphabet for bases beyond 16.  Using the letter L at
>> the end of a number to indicate double precision numbers prevents the
>> use of bases beyond... well, some point.  Base 21 I think.  Not at all
>> sure if this feature is used much or even at all.
>
> 'base' is used.
>
> Sample in 8th for random password generation using base-36 (ten digits
> and 26 letters):
>
> : rand-range \ low hi -- rand
> 	n:1+ over n:- rand n:abs
> 	swap n:mod n:+ ;
>
> : base36 \ n -- s
> 	36 base
> 	swap >s
> 	swap base drop ;
>
> : gen-pwd
> 	10000000000
> 	999999999999999
> 	rand-range
> 	base36 ;
>
> "Password: " .
> gen-pwd . cr bye

What is ">s"?

My statement was a bit too broad.  Using an L as a suffix for double 
precision numbers does not prevent the use of higher bases, it prevents 
the input of numbers in higher bases that end in L.  I don't see a 
compatibility problem  with the above code.

-- 

Rick C

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

#48737

From	Ron Aaron <rambamist@gmail.com>
Date	2016-07-03 10:20 +0300
Message-ID	<nlaebr$qt6$1@dont-email.me>
In reply to	#48734


On 07/03/2016 10:00, rickman wrote:

> What is ">s"?

Convert a number (or anything else, really) to a string

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

#48740

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-07-03 08:29 +0000
Message-ID	<2016Jul3.102958@mips.complang.tuwien.ac.at>
In reply to	#48734

rickman <gnuarm@gmail.com> writes:
>My statement was a bit too broad.  Using an L as a suffix for double 
>precision numbers does not prevent the use of higher bases, it prevents 
>the input of numbers in higher bases that end in L.

Not quite: If the number is interpreted as double, and you want a
single, you can write "...LL drop".  But it's a pitfall: A user could
easily write "...L" and expect the L to be interpreted as a digit, and
the mistake might not be found out until much later.  The purpose of
the RfD is to get rid of a pitfall, not to introduce a new one.

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

#48732

From	hughaguilar96@gmail.com
Date	2016-07-02 23:10 -0700
Message-ID	<4a212a8d-540b-4ba3-a324-4e56c7b81650@googlegroups.com>
In reply to	#48730

On Saturday, July 2, 2016 at 10:16:45 PM UTC-7, rickman wrote:
> On 7/2/2016 6:32 PM, WJ wrote:
> > hughaguilar96@gmail.com wrote:
> >
> >>> How about a trailing underscore for designating a double number, e.g.
> >>>
> >>>   1_
> >>>
> >>> ?
> >>
> >> I would be okay with that ---
> >
> > OCaml uses a trailing L to indicate a 64-bit integer:
> >
> > # 8_123_456_789L ;;
> > - : int64 = 8123456789L
> >
> > Like Ruby, OCaml allows the user to insert underscores for
> > readability.
> 
> The letter L is ok I suppose, but I have read that Forth supports using 
> any letters of the alphabet for bases beyond 16.  Using the letter L at 
> the end of a number to indicate double precision numbers prevents the 
> use of bases beyond... well, some point.  Base 21 I think.  Not at all 
> sure if this feature is used much or even at all.
> 
> -- 
> 
> Rick C

I mark all of WJ's posts as being abusive so they become hidden. He is just a troll. Posting OCaml code (or Gauche Scheme code or whatever) on a Forth forum is spam. Also, his taglines referencing rape of women and children are offensive. Also, his unsolicited support for me (calling Leon Wagner a "neanderthal") is offensive --- I don't want him to support me --- neither do the OCaml or Gauche Scheme developers want him to support them, etc..

Now we have the troll Rickman responding to the troll WJ's posts --- are WJ's posts not actually being hidden? --- is Rickman removing the abusive tag from them so he can respond to them?

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

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

csiph-web

RfD: new double syntax

Contents

#48647 — RfD: new double syntax

#48650

#48651

#48652

#48705

#48653

#48700

#48657

#48671

#48682

#48675

#48677

#48680

#48716

#48730

#48731

#48734

#48737

#48740

#48732