Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46423 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2016-04-02 17:49 -0400 |
| Last post | 2016-05-06 20:37 -0400 |
| Articles | 20 on this page of 95 — 28 participants |
Back to article view | Back to comp.lang.forth
Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-02 17:49 -0400
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-03 06:23 +0000
Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-03 02:59 -0400
Re: Decimal Point vs. Decimal Comma Coos Haak <chforth@hccnet.nl> - 2016-04-03 17:33 +0200
Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-03 21:21 -1000
Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-04 01:42 -0700
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-04 02:00 -0700
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 10:00 +0000
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-04 03:04 -0700
Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-04 11:16 -1000
Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-03 23:28 -1000
Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-04 02:38 -0700
Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-04 11:09 -1000
Re: Decimal Point vs. Decimal Comma "HAA" <someone@microsoft.com> - 2016-04-08 00:18 +1000
Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-08 03:27 -0500
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 08:30 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-08 12:00 +0300
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 10:25 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-08 13:34 +0300
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 11:46 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-08 15:20 +0300
Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-08 04:08 -0500
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 10:26 +0000
Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-08 10:37 -0500
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 15:28 +0000
Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-09 10:17 -0700
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-11 14:45 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-12 10:18 +0300
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-08 09:05 -0700
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-08 10:14 -0700
Re: Decimal Point vs. Decimal Comma Julian Fondren <julian.fondren@gmail.com> - 2016-04-08 15:51 -0700
Re: Decimal Point vs. Decimal Comma Julian Fondren <julian.fondren@gmail.com> - 2016-04-08 16:11 -0700
Re: Decimal Point vs. Decimal Comma "WJ" <w_a_x_man@yahoo.com> - 2016-05-09 01:16 +0000
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 22:18 +0000
Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-08 20:33 -0700
Re: Decimal Point vs. Decimal Comma mhx@iae.nl - 2016-04-09 01:20 -0700
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 11:03 +0000
Re: Decimal Point vs. Decimal Comma mhx@iae.nl - 2016-04-09 01:29 -0700
Double and FP syntax (was: Decimal Point vs. Decimal Comma) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 09:19 +0000
Re: Double and FP syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-04-09 14:25 -1000
Re: Double and FP syntax hughaguilar96@gmail.com - 2016-04-10 21:48 -0700
Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma) stephen@mpeforth.com (Stephen Pelc) - 2016-04-15 10:17 +0000
Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma) hughaguilar96@gmail.com - 2016-04-17 16:48 -0700
Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-24 16:03 +0000
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:27 +0000
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 08:52 +0000
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-03 23:14 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 07:18 +0300
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 07:48 +0300
Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-03 09:45 +0300
Re: Decimal Point vs. Decimal Comma Nils M Holm <nmh@ananda.local> - 2016-04-03 07:32 +0000
Re: Decimal Point vs. Decimal Comma George Neuner <gneuner2@comcast.net> - 2016-04-03 05:25 -0400
Re: Decimal Point vs. Decimal Comma Robert Wessel <robertwessel2@yahoo.com> - 2016-04-03 17:22 -0500
Re: Decimal Point vs. Decimal Comma Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2016-04-03 14:05 +0200
Re: Decimal Point vs. Decimal Comma Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-04-03 14:18 +0200
Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-03 20:24 +0300
Re: Decimal Point vs. Decimal Comma Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-04-03 21:05 +0300
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:00 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-03 21:16 +0300
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:17 +0000
Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 12:46 +0300
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 06:02 +0000
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-03 23:21 +0000
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-04 07:11 +0000
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-04 21:11 +0000
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-03 19:27 -0700
Re: Decimal Point vs. Decimal Comma Robert Wessel <robertwessel2@yahoo.com> - 2016-04-04 00:13 -0500
Re: Decimal Point vs. Decimal Comma "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2016-04-04 14:06 +0200
Re: Decimal Point vs. Decimal Comma Nobody <nobody@nowhere.invalid> - 2016-04-05 03:32 +0100
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-04 19:52 -0700
Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-05 09:56 +0300
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-05 00:13 -0700
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 09:44 +0000
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-05 12:38 +0000
Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-05 10:03 +0000
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 21:42 +0000
Re: Decimal Point vs. Decimal Comma George Neuner <gneuner2@comcast.net> - 2016-04-05 11:11 -0400
Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-05 11:33 -0500
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-05 11:58 -0700
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-06 12:50 +0000
Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 07:15 +0000
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-05 01:12 -0700
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 21:50 +0000
Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-06 01:18 +0300
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-05 23:47 -0700
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 23:11 +0000
Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-09 03:19 +0300
Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-08 22:06 -0700
Re: Decimal Point vs. Decimal Comma mac <acolvin@efunct.com> - 2016-04-11 18:52 +0000
Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-11 23:39 +0300
Re: Decimal Point vs. Decimal Comma endlessboomcapitalism@gmail.com - 2016-05-02 15:29 -0700
Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-05-02 22:27 -0400
Re: Decimal Point vs. Decimal Comma Gerard Sontag <gerardsontag@gmail.com> - 2016-05-03 05:06 -0700
Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-06 23:42 +0000
Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-05-06 20:37 -0400
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-04-08 15:20 +0300 |
| Message-ID | <ne87gj$tg3$1@dont-email.me> |
| In reply to | #46589 |
On 08/04/2016 14:46, Anton Ertl wrote: > The problem was that I expected that Gforth, after accepting "2,", > would do one thing, and it actually did something completely > different. This kind of miscommunication between programmer and > compiler does not happen in a well-designed language, and since "," as > double indicator is non-standard, was easy to fix in this case. > Standardized misfeatures along these lines like "." meaning > double-cell when programmers coming from other languages expect it to > mean FP (or, e.g., the meaning of "if (x=y)" in C) are harder nuts to > crack. True. That's why I dropped the "accept commas in numbers" in 8th towards the beginning of the beta testing. It's just cleaner; and if you really need to accept comma-ed numbers on input, you can (and should) process them specifically. Output is another story...
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-04-08 04:08 -0500 |
| Message-ID | <dt6dnUt7ENie6JrKnZ2dnUU7-bmdnZ2d@supernews.com> |
| In reply to | #46583 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I disagree. We're talking about something which has been in use for >>forty-odd years, and has not turned out do be dangerous. I think we'd >>know by now if it was. > > As I already reported, >20 years ago I tried to use "2," as a two-cell > variant of ",", and Gforth did not report an error, but interpreted > the "2," in a (by me) totally unexpected way. > > As a reaction to that, Gforth now accepts only numbers with "." as > double numbers. This has not led to any complaints. My conclusion is > that other double indicators are not just dangerous, but also > unnecessary. That seems like an over-reaction to a minor problem. A much more major problem is that this stuff has been useful in real Forth applications for a long time, and has proved to be useful. Sure, it's not absolutely necessary, but then neither is 2DUP. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-04-08 10:26 +0000 |
| Message-ID | <2016Apr8.122641@mips.complang.tuwien.ac.at> |
| In reply to | #46585 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> As a reaction to that, Gforth now accepts only numbers with "." as
>> double numbers. This has not led to any complaints. My conclusion is
>> that other double indicators are not just dangerous, but also
>> unnecessary.
>
>That seems like an over-reaction to a minor problem.
It's the appropriate reaction.
> A much more
>major problem is that this stuff has been useful in real Forth
>applications for a long time, and has proved to be useful.
Not only did we not receive complaints about the absence of this
misfeature, IIRC we did not receive any feature requests from users,
either. No, definitely not a major problem, not even a minor one. I
guess this stuff is as useful as the "optimization opportunities"
resulting from "undefined behaviour": Something the fans of the
feature like to tout in postings, but for good reasons they don't
provide any empirical evidence.
What is a major problem is the standard double number syntax. For a
newcomer, "1." does something completely unexpected, and pretty
puzzling. And when you explain what it does, the image of an obsolete
language will consolidate. We should switch to a different doubles
syntax so that we can (eventually, after a long cooldown time) use
"1." for FP.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-04-08 10:37 -0500 |
| Message-ID | <wvudnUW0RY-7TZrKnZ2dnUU7-LGdnZ2d@supernews.com> |
| In reply to | #46588 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>A much more major problem is that this stuff has been useful in real >>Forth applications for a long time, and has proved to be useful. > > Not only did we not receive complaints about the absence of this > misfeature, IIRC we did not receive any feature requests from users, > either. Well, no, but the people used to this working are Forth, Inc. customers, and I suspect that the number of their customers switching to GForth is rather small. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-04-09 15:28 +0000 |
| Message-ID | <2016Apr9.172854@mips.complang.tuwien.ac.at> |
| In reply to | #46592 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>A much more major problem is that this stuff has been useful in real
>>>Forth applications for a long time, and has proved to be useful.
>>
>> Not only did we not receive complaints about the absence of this
>> misfeature, IIRC we did not receive any feature requests from users,
>> either.
>
>Well, no, but the people used to this working are Forth, Inc.
>customers, and I suspect that the number of their customers switching
>to GForth is rather small.
I don't know about switching, but I did get that IBM and Apple have
used Gforth in their Open Firmware work, and they were Forth,
Inc. customers (they took courses at Forth, Inc.).
Anyway, this misfeature is not a secret known only to Forth,
Inc. customers, on the contrary, it is touted here (and presumably
elsewhere) quite regularly. Apparently that was not convincing enough
to incite even one Gforth user to ask for it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-09 10:17 -0700 |
| Message-ID | <87egaeog5a.fsf@nightsong.com> |
| In reply to | #46611 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Anyway, this misfeature is not a secret known only to Forth, > Inc. customers, on the contrary, it is touted here (and presumably > elsewhere) quite regularly. Apparently that was not convincing enough > to incite even one Gforth user to ask for it. Now that I understand it, I think it is a cute idea, but I won't go as far as to ask for it in Gforth. There is probably a better approach using recognizers.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-04-11 14:45 +0000 |
| Message-ID | <2016Apr11.164546@mips.complang.tuwien.ac.at> |
| In reply to | #46612 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Anyway, this misfeature is not a secret known only to Forth,
>> Inc. customers, on the contrary, it is touted here (and presumably
>> elsewhere) quite regularly. Apparently that was not convincing enough
>> to incite even one Gforth user to ask for it.
>
>Now that I understand it, I think it is a cute idea, but I won't go as
>far as to ask for it in Gforth. There is probably a better approach
>using recognizers.
These days, sure. E.g., recognizers allow you to distinguish between
1/11/2016 and 11/1/2016, and let the latter produce the same result as
11/01/2016.
However, recognizers are a recent addition, and not yet present in any
released version of Gforth. So they are not the reason why nobody has
asked for this feature. My guess is that it is superficially cute,
but lacking in practice. Usage examples given were:
Dates: There you have the problem of significant separator placement
indicated above. Ok, tell the user to always use two-digit month and
day names, but without input checking, this would be too brittle for
my taste.
Telephone numbers: Here separators can be placed anywhere (most of the
time, see below), but SwiftForth does not accept all characters that
customarily appear in telephone numbers, e.g.:
(+43)-1-58801-18515
Also, leading zeros and the + here are significant. So the feature
does not quite cut it for this example, either.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-04-12 10:18 +0300 |
| Message-ID | <nei7b5$tnc$1@dont-email.me> |
| In reply to | #46624 |
Two different implementations for allowing commas in input numbers in 8th: http://8th-dev.com/forum/index.php/topic,903.0.html One uses the interpreter's 'last gasp' word; the second uses a more proactive approach. Neither satisfactorily addresses numbers inside JSON arrays, which is the main reason 8th abandoned allowing commas in input numbers while still in early beta.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-08 09:05 -0700 |
| Message-ID | <a203edfe-c9a0-40c4-91bc-cfac3c4c0862@googlegroups.com> |
| In reply to | #46588 |
On Friday, April 8, 2016 at 3:38:06 AM UTC-7, Anton Ertl wrote: > What is a major problem is the standard double number syntax. For a > newcomer, "1." does something completely unexpected, and pretty > puzzling. And when you explain what it does, the image of an obsolete > language will consolidate. We should switch to a different doubles > syntax so that we can (eventually, after a long cooldown time) use > "1." for FP. The idea that you are going to break compatibility with ANS-Forth over a "long cool-down time" is ridiculous. This reminds me of a little kid entering the swimming pool on a hot day from the shallow end and giving himself a long cool-down period during which he takes two steps forward so the water level rises two inches on his legs and then stands there shivering for 5 minutes before taking another two steps forward, etc.. This is really not going to work! Eventually it is time for the swimming pool to close for the day and he has only gotten far enough for the water level to be up to his chest, but he hasn't done any swimming and his day has been nothing but misery. The solution, as I've said many times, is to have a new standard (lets call it FloatForth) that is incompatible with ANS-Forth. For a period of time both standards will coexist and the compiler vendors will have to support both standards (Stephen Pelc is the only one who is still in business, as Ray Duncan gave up on Forth after ANS-Forth became the standard). Over a period of a few years Forthers will either stick with ANS-Forth (indicating that E.R. is a genius and that I'm an idiot) or migrate to FloatForth (indicating the opposite). There is not much legacy Forth code still in use, so it shouldn't be all that much work to port it to FloatForth --- we are programmers, so we are supposed to know how our code works and be capable of porting it --- only sales-people fear porting code because they don't know how it works and they are afraid that the whole program will stop working and nobody will know how to make it work again. This is what Elizabeth Rather says: On Monday, April 4, 2016 at 2:28:55 AM UTC-7, Elizabeth D. Rather wrote: > From the SwiftForth manual (and every other manual from us since 1973): > "Punctuation in a number (decimal point, comma, colon, slash, or dash > anywhere other than before the leftmost digit) will cause the number to > be converted as a double number." This is convenient because you can, > for example, type a date like 4/01/2016 and it will go on the stack as a > double, to be passed directly to a word that will convert it as a date. > Likewise times, angles, and other formatted numbers. It's really a very > convenient convention. She is fixated on holding Forth at the 1970s level forever. She believes that Charles Moore was a genius (arguably true) and that every design decision he made in the 1970s must be held onto forever as if it were carved into tablets of stone and carried down from Mt. Sinai (certainly not true). This design decision was made by C.M. at a time when he did not foresee Forth ever having floating-point. Allowing the slash made dates convenient but it conflicted with 2/ etc.. Allowing the hyphen made social-security numbers convenient but it conflicted with 2- etc.. These are bugs in the design, but E.R. will never admit that C.M. has ever had a bug in his code in his life. She appointed you to the job of Forth-200x chair-person and she expects total loyalty from you, so she will never allow you to admit that there is anything wrong with ANS-Forth and allow Forth-200x to break compatibility with ANS-Forth. E.R. is just spouting nonsense anyway. If 4/01/2016 is interpreted as a double-precision number 4012016 then you still have dumped a complicated problem on the application programmer to extract the month, day and year from the number. Also, 1212016 could be interpreted either as the 1st of December or the 21st of January --- ambiguity! --- but E.R. has no problem with ambiguity, and in fact seems to like ambiguity. Similarly if 12:34:56 is interpreted as 123456 then the application programmer has the problem of extracting the hour, minute and second from the number. This is not "convenient" at all! Currently I have STR>INT and STR>FLT as well as STR>NUM that calls STR>INT first and if that doesn't work then calls STR>FLT next (STR>NUM would be used in the outer-intepreter). These allow commas, and require a comma as the first char for doubles, so FloatForth can't have 2, etc.. this is not a problem because FloatForth has D, instead (note that $D, would be interpreted as a single-precision hexadecimal integer). I could write STR>DATE that would convert a string such as 4/01/2016 and 4/1/2016 into month, day and year integers. I could also write STR>TIME that would convert a string such as 12:34:56 or 12:34:56.789 into hour, minute and second floats. STR>DATE and STR>TIME would be used by the application programmer for converting strings that the user enters. STR>NUM (used in the outer-interpreter) can be upgraded to support STR>DATE and STR>TIME --- this will still allow words such as 2/ to be available because STR>DATE will not consider this to be a valid date (you need two / marks separating three numbers, and the numbers have to be in the correct range). That would actually be convenient! I can write STR>INT and STR>FLT (already done), as well as STR>DATE and STR>TIME (not done yet) because I'm a programmer --- actually, any competent programmer should be able to write these functions --- being a programmer is all about writing code, a fact that E.R. has been dodging since the 1970s (I doubt she was any good at COBOL either, which is what she did prior to becoming the self-proclaimed "leading expert" on Forth in 1974). The only way for Forth to advance beyond the 1970s level is for us to free ourselves from Elizabeth Rather --- she is like a boat anchor tied to our ankles that keeps us in the harbor while the rest of the world sails over the horizon into the future.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-08 10:14 -0700 |
| Message-ID | <50d1b924-f7d8-4708-b253-b728398c7905@googlegroups.com> |
| In reply to | #46593 |
On Friday, April 8, 2016 at 9:05:02 AM UTC-7, hughag...@gmail.com wrote: > I could write STR>DATE that would convert a string such as 4/01/2016 and 4/1/2016 into month, day and year integers. ... this will still allow words such as 2/ to be available because STR>DATE will not consider this to be a valid date (you need two / marks separating three numbers, and the numbers have to be in the correct range). I don't think that 2/ is needed anymore anyway. In the 1970s C.M. wasn't doing any optimization at all. This was because the computers (such as the PDP-11) had so little memory that there wasn't room for an optimizing compiler, and besides that C.M. was mostly focusing on getting the system to work rather than optimizing it. Words like 2/ were provided because 2 / wasn't getting optimized by the compile and so 2/ was much more efficient. We didn't have 4/ though because it was not expected to get used enough to justify the memory it takes up in the dictionary, and besides that you can't have too many words in the dictionary or the user's learning curve is too steep due to having too much to remember. SwiftForth version-3 continues to do almost no optimization at all, pretty much the same as in the 1970s: : optimal 2/ ; ok see optimal 478F3F EBX SAR D1FB 478F41 RET C3 ok : nonoptimal 2 / ; ok see nonoptimal 478F5F EBX EAX MOV 8BC3 478F61 CDQ 99 478F62 2 # EBX MOV BB02000000 478F67 EBX IDIV F7FB 478F69 EAX EBX MOV 8BD8 478F6B RET C3 ok SwiftForth is an unfunny joke --- nobody cares about this primitive nonsense in the year 2016 --- we don't need 2/ anymore. The reason why ANS-Forth has 2/ as a standard word is because in 1994 nobody at Forth Inc. knew how to write an optimizing compiler that would compile 2 / efficiently --- Elizabeth Rather's goal in writing the ANS-Forth standard was to hold the entire Forth community down at her level of incompetence. I intend to make FloatForth interpret any integer with a + - * or / suffix as that integer followed by + - * or / respectively. This would just be a convenience to make the source-code shorter and more readable --- writing 2 / would generate the same optimized code as 2/ though. Also, btw, I can have +! -! *! /! and! etc. --- these would bring Forth up to the level of C that has += -= *= /= &= etc..
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-04-08 15:51 -0700 |
| Message-ID | <1d322ed0-15a3-4ea2-bed5-a9afc7087925@googlegroups.com> |
| In reply to | #46594 |
On Friday, April 8, 2016 at 12:14:13 PM UTC-5, hughag...@gmail.com wrote: > > SwiftForth version-3 continues to do almost no optimization at all, pretty much the same as in the 1970s: > > : optimal 2/ ; ok > see optimal > 478F3F EBX SAR D1FB > 478F41 RET C3 ok > > : nonoptimal 2 / ; ok > see nonoptimal > 478F5F EBX EAX MOV 8BC3 > 478F61 CDQ 99 > 478F62 2 # EBX MOV BB02000000 > 478F67 EBX IDIV F7FB > 478F69 EAX EBX MOV 8BD8 > 478F6B RET C3 ok > $ sf SwiftForth i386-Linux 3.5.9 12-Nov-2015 package optimizing-compiler ok : literal-/ lastlit @ 2 = if postpone 2/ else lastlit @ postpone literal postpone / then ; ok optimize (literal) / with literal-/ ok end-package ok : x 2/ ; : y 2 / ; ok see x 808398F EBX SAR D1FB 8083991 RET C3 ok see y 80839AF EBX SAR D1FB 80839B1 RET C3 ok -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-04-08 16:11 -0700 |
| Message-ID | <19a3b982-156f-4dff-a87b-98c96a01eb03@googlegroups.com> |
| In reply to | #46596 |
On Friday, April 8, 2016 at 5:51:28 PM UTC-5, Julian Fondren wrote: > : literal-/ lastlit @ 2 = if postpone 2/ else lastlit @ postpone literal postpone / then ; Heh, that actually results in infinite optimization of : x 3 / ; Well the point was just to demonstrate the extensible optimizer. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-05-09 01:16 +0000 |
| Message-ID | <ngood0$sdu$1@dont-email.me> |
| In reply to | #46593 |
hughaguilar96@gmail.com wrote:
> I could write STR>DATE that would convert a string such as
> 4/01/2016 and 4/1/2016 into month, day and year integers.
In Europe, the day comes before the month.
The Posix format is preferred:
2016-04-01
OCaml:
#load "str.cma";;
let parse_date str =
str
|> Str.split (Str.regexp "[^0-9]+")
|> List.map int_of_string ;;
parse_date "2016-03-08";;
: int list = [2016; 3; 8]
parse_date "2016/03/08";;
: int list = [2016; 3; 8]
parse_date " 2016 / 03 / 08 ";;
: int list = [2016; 3; 8]
parse_date " 2016 03 08 ";;
: int list = [2016; 3; 8]
parse_date " The date is: 2016 03 08 Understand??? ";;
: int list = [2016; 3; 8]
--
I don't believe in western morality, i.e. don't kill civilians or children....
The only way to fight a moral war is the Jewish way: Destroy their holy sites.
Kill men, women and children (and cattle). --- Rabbi Manis Friedman
web.archive.org/web/20090605154706/http://www.momentmag.com/Exclusive/2009/2009-06/200906-Ask_Rabbis.html
archive.org/download/DavidDukeVideo/TheZionistMatrixOfPowerddhd.ogv
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-04-08 22:18 +0000 |
| Message-ID | <ne9ao1$2gt$1@dont-email.me> |
| In reply to | #46588 |
Am Fri, 08 Apr 2016 10:26:41 +0000 schrieb Anton Ertl: > What is a major problem is the standard double number syntax. For a > newcomer, "1." does something completely unexpected, and pretty > puzzling. And when you explain what it does, the image of an obsolete > language will consolidate. We should switch to a different doubles > syntax so that we can (eventually, after a long cooldown time) use "1." > for FP. Actually, your first move (and the narrowing down of the standard to only accept a trailing '.' as indicator of double numbers) makes it rather more than less difficult to switch over, because now, there's no other portable way to indicate doubles. Having an other way would make it easier to deprecate one way. VFX by default for quite some time accepted only ',' as indicator for double numbers, and has '.' for floats. That's non-standard, and broke e.g. MINOS, so the MINOS harness sets dp-char to '.', and then compiles. That's also bad, because then, other programs written for VFX don't load... but the general idea is in the right direction. I've added dp-char and fp-char to Gforth, so we again have at least that path open now: Set dp-char to ',', and you can suddenly enter 1. and it is a floating point number. This happens, because the floating point recognizer is also less strict than the standard, but normally doesn't catch the numbers with a '.' in them, because that goes to the double number recognizer. Change the separator, and you are done: ',' dp-char ! ok 1. f. 1. ok 1.23 f. 1.23 ok 1,23 d. 123 ok Given that double numbers are less often used on 32 and 64 bit Forth, and floating point is now fast and available, using the '.' to mark floating point is more convenient. VFX has a list of separators, so you can emulate Forth Inc's behavior, too. So a way to proceed would be to standardize dp-char and fp-char, and tell the newbies to put a ',' dp-char ! at the start of their programs and into their .gforthrc (for interactive use). Of course, having such a global state is again a "bad idea", like BASE... A library that decides to use a particular indicator for doubles must restore the previous state... -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-08 20:33 -0700 |
| Message-ID | <87inzro3q9.fsf@nightsong.com> |
| In reply to | #46595 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Actually, your first move (and the narrowing down of the standard to only > accept a trailing '.' as indicator of double numbers) makes it rather > more than less difficult to switch over, Yeah I was surprised that . meant a double integer, and particularly that 3.14159 and 314.159 were the exact same double integer.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-04-09 01:20 -0700 |
| Message-ID | <e9200251-c24b-4a4d-8ab3-1a1c5411be04@googlegroups.com> |
| In reply to | #46601 |
On Saturday, April 9, 2016 at 5:33:57 AM UTC+2, Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
> > Actually, your first move (and the narrowing down of the standard to only
> > accept a trailing '.' as indicator of double numbers) makes it rather
> > more than less difficult to switch over,
>
> Yeah I was surprised that . meant a double integer, and particularly
> that 3.14159 and 314.159 were the exact same double integer.
That has always been the case in Forth. It never caused any
problems because all Forths had something called DPL:
DPL
( -- a-addr )
a-addr is the address of DPL . DPL contains the "decimal point" location
if a double number is input, measured from the right. If a single number
is input, DPL contains -1. DPL always contains 0 for double numbers if
ANSI is ON . iForth allows several other characters to signal double
numbers apart from '.' (full stop). In the case that more than one
decimal point is present DPL points to the last one.
See also: >NUMBER CONVERT NUMBER?
You can find references to DPL in already in Starting Forth.
That people now say they have problems with '.' and
numbers is because some Standard committee has decided
to remove DPL, and only allow '.' at a specific position
to indicate a double number, without supplying an
alternative.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-04-09 11:03 +0000 |
| Message-ID | <2016Apr9.130347@mips.complang.tuwien.ac.at> |
| In reply to | #46604 |
mhx@iae.nl writes:
>That people now say they have problems with '.' and
>numbers is because some Standard committee has decided
>to remove DPL, and only allow '.' at a specific position
>to indicate a double number, without supplying an
>alternative.
The first problem is that people coming from other languages expect
1. to be an FP number. This has nothing to do with the committee not
standardizing 1.0 or DPL. Admittedly, people may also write 1.0 and
expect that to produce an FP number, and that most systems accept that
and produce a double number is also a problem; that problem is not
solved with DPL, and the standard is not responsible for that;
instead, the individual system implementors are.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-04-09 01:29 -0700 |
| Message-ID | <f56f3288-15fe-4f83-a466-df83d56a2d18@googlegroups.com> |
| In reply to | #46601 |
On Saturday, April 9, 2016 at 5:33:57 AM UTC+2, Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
> > Actually, your first move (and the narrowing down of the standard to only
> > accept a trailing '.' as indicator of double numbers) makes it rather
> > more than less difficult to switch over,
>
> Yeah I was surprised that . meant a double integer, and particularly
> that 3.14159 and 314.159 were the exact same double integer.
That has always been the case. It never caused any
problems because Forth had something called DPL:
DPL
( -- a-addr )
a-addr is the address of DPL . DPL contains the "decimal point" location
if a double number is input, measured from the right. If a single number
is input, DPL contains -1. DPL always contains 0 for double numbers if
ANSI is ON . iForth allows several other characters to signal double
numbers apart from '.' (full stop). In the case that more than one
decimal point is present DPL points to the last one.
See also: >NUMBER CONVERT NUMBER?
You can find references to DPL in Starting Forth.
That people now say they have problems with '.' and
numbers is because a Standard Improvement Committee has
decided to remove DPL, and only to allow '.' at a fixed
position to indicate a double number, without supplying
a useful alternative to get back the functionality and
flexibility that always existed.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-04-09 09:19 +0000 |
| Subject | Double and FP syntax (was: Decimal Point vs. Decimal Comma) |
| Message-ID | <2016Apr9.111900@mips.complang.tuwien.ac.at> |
| In reply to | #46595 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Fri, 08 Apr 2016 10:26:41 +0000 schrieb Anton Ertl:
>> What is a major problem is the standard double number syntax. For a
>> newcomer, "1." does something completely unexpected, and pretty
>> puzzling. And when you explain what it does, the image of an obsolete
>> language will consolidate. We should switch to a different doubles
>> syntax so that we can (eventually, after a long cooldown time) use "1."
>> for FP.
>
>Actually, your first move (and the narrowing down of the standard to only
>accept a trailing '.' as indicator of double numbers) makes it rather
>more than less difficult to switch over, because now, there's no other
>portable way to indicate doubles. Having an other way would make it
>easier to deprecate one way.
We discussed the issue at the 2014 Forth-200x meeting, and my notes
about that say:
|Input: We may want a way to make 100. an FP number in the text
|interpreter. And a way to allow a more liberal FP number. Solution:
|use prefixes: *123 and *$-a for doubles and !1 for floats. At some
|point we deprecate "1." as long, and systems are free to use 1. as FP
|number. Allow "," in >float and in prefixed floats. For FP numbers,
|the last separator is the decimal separator. Action: SP
I don't remember why we wanted another floating-point syntax, but at
the time, among a few options, we selected a * prefix as double
indicator.
You seem to suggest having a "," anywhere in the number as double
indicator. For some reason nobody (not even you) suggested that at
the time. Is it a good idea? Advantages: many Forth systems
understand it already, so it's relatively common practice.
Disadvantages: a) confusion with the word "2,"; b) "," is visually
(and on my (US-layout) keyboard physically) close to ".", making it
harder to see a mistake in that area (remember the story about the "DO
5 K=1.3" mistake, which apparently did not have the expensive
consequences often attributed to it
<http://catless.ncl.ac.uk/Risks/9.54.html#subj1.1>).
>VFX by default for quite some time accepted only ',' as indicator for
>double numbers, and has '.' for floats. That's non-standard, and broke
>e.g. MINOS, so the MINOS harness sets dp-char to '.', and then compiles.
>That's also bad, because then, other programs written for VFX don't
>load... but the general idea is in the right direction.
The general idea to go away from "." for doubles and use something
else is in the right direction, yes. The general idea of DP-CHAR is
bad, as demonstrated above.
>I've added dp-char and fp-char to Gforth, so we again have at least that
>path open now: Set dp-char to ',', and you can suddenly enter 1. and it
>is a floating point number.
That's a bad idea. A standard usage of 1. will suddenly do something
completely different, without warning, because someone somewhere
changed DP-CHAR.
>So a way to proceed would be to standardize dp-char and fp-char, and tell
>the newbies to put a ',' dp-char ! at the start of their programs and
>into their .gforthrc (for interactive use).
Over my dead body.
The syntax is something we have to decide as a community. Chickening
out by providing configuration options (and worse, as global state) to
individual programmers only leads to problems. System implementors
may decide to inflict such problems on their users by providing such
options in order to support legacy code (but a conversion tool would
be better), but such kludges have no place in the standard.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-04-09 14:25 -1000 |
| Subject | Re: Double and FP syntax |
| Message-ID | <J9qdncQMGaQLAJTKnZ2dnUU7-afNnZ2d@supernews.com> |
| In reply to | #46607 |
On 4/8/16 11:19 PM, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Am Fri, 08 Apr 2016 10:26:41 +0000 schrieb Anton Ertl: >>> What is a major problem is the standard double number syntax. For a >>> newcomer, "1." does something completely unexpected, and pretty >>> puzzling. And when you explain what it does, the image of an obsolete >>> language will consolidate. We should switch to a different doubles >>> syntax so that we can (eventually, after a long cooldown time) use "1." >>> for FP. This issue is only one of a great many unexpected things the newcomer has to learn in order to use Forth. Having a test precede IF, for example, and postfix notation in general, are hurdles, even though they are minor ones easily accommodated, in my experience. "1." is just another, and a pretty minor one. ... > We discussed the issue at the 2014 Forth-200x meeting, and my notes > about that say: > > |Input: We may want a way to make 100. an FP number in the text > |interpreter. And a way to allow a more liberal FP number. Solution: > |use prefixes: *123 and *$-a for doubles and !1 for floats. At some > |point we deprecate "1." as long, and systems are free to use 1. as FP > |number. Allow "," in >float and in prefixed floats. For FP numbers, > |the last separator is the decimal separator. Action: SP > > I don't remember why we wanted another floating-point syntax, but at > the time, among a few options, we selected a * prefix as double > indicator. Appalling. Programmers aren't the only people who type numbers to a Forth program, users do, as well. The whole concept of how the text interpreter processes numbers, from ~1970 on, has been to let users type numbers in as natural a way as possible. Human nature (expressed in the Rule of 7) means that most all large numbers are broken up by some kind of punctuation, so by accepting them as doubles, data entry becomes quite natural. Further validation is the province of the application. The current awkwardness is caused by the fact that all those early systems were mostly 16-bit and integer based, as they were on platforms for which floating poing was a major performance hog. For many microcontrollers, a major remaining application domain for Forth, this is still often the case, while on PCs FP is fast and ubiquitous and the cell size is at least 32 bits. The essential difficulty is finding a way to accommodate both camps. ... >> VFX by default for quite some time accepted only ',' as indicator for >> double numbers, and has '.' for floats. That's non-standard, and broke >> e.g. MINOS, so the MINOS harness sets dp-char to '.', and then compiles. >> That's also bad, because then, other programs written for VFX don't >> load... but the general idea is in the right direction. > > The general idea to go away from "." for doubles and use something > else is in the right direction, yes. The general idea of DP-CHAR is > bad, as demonstrated above. > >> I've added dp-char and fp-char to Gforth, so we again have at least that >> path open now: Set dp-char to ',', and you can suddenly enter 1. and it >> is a floating point number. > > That's a bad idea. A standard usage of 1. will suddenly do something > completely different, without warning, because someone somewhere > changed DP-CHAR. > >> So a way to proceed would be to standardize dp-char and fp-char, and tell >> the newbies to put a ',' dp-char ! at the start of their programs and >> into their .gforthrc (for interactive use). > > Over my dead body. > > The syntax is something we have to decide as a community. Chickening > out by providing configuration options (and worse, as global state) to > individual programmers only leads to problems. System implementors > may decide to inflict such problems on their users by providing such > options in order to support legacy code (but a conversion tool would > be better), but such kludges have no place in the standard. Agreed. 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]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web