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

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

RFD: Drop double numbers as input format

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

Contents

  RFD: Drop double numbers as input format Matthias Trute <matthias.trute@gmail.com> - 2017-06-04 01:25 -0700
    Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:45 -0500
    Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 02:10 -0700
      Re: RFD: Drop double numbers as input format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-04 12:12 +0200
        Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 02:32 -0500
          Re: RFD: Drop double numbers as input format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-05 10:19 +0200
            Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-05 09:14 +0000
              Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 04:57 -0500
            Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 04:51 -0500
          Re: RFD: Drop double numbers as input format Cecil Bayona <cbayona@cbayona.com> - 2017-06-05 11:53 -0500
            Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 12:29 -0500
            Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-05 11:20 -0700
              Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-05 11:25 -0700
                Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 00:50 -0700
                  Re: RFD: Drop double numbers as input format stephen@mpeforth.com (Stephen Pelc) - 2017-06-06 10:16 +0000
                    Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 05:30 -0700
                Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 22:54 -0700
            Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 02:12 -0700
              Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-06 04:23 -0500
                Re: RFD: Drop double numbers as input format Cecil Bayona <cbayona@cbayona.com> - 2017-06-06 10:26 -0500
              Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-06 09:52 +0000
                Re: RFD: Drop double numbers as input format Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 04:57 -0700
                Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:01 -0700
                Re: RFD: Drop double numbers as input format Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-06-06 18:07 +0100
              Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-06 08:09 -0700
                Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 11:51 -0700
                  Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-06 12:19 -0700
        Re: RFD: Drop double numbers as input format Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-06-10 23:23 +0100
      Re: RFD: Drop double numbers as input format Paul Rubin <no.email@nospam.invalid> - 2017-06-04 17:05 -0700
        Re: RFD: Drop double numbers as input format rickman <gnuarm@gmail.com> - 2017-06-04 21:38 -0400
        Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-04 20:26 -0700
          Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-05 00:01 -0700
            Re: RFD: Drop double numbers as input format Matthias Trute <matthias.trute@gmail.com> - 2017-06-05 01:18 -0700
        Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 23:47 -0700
        Re: RFD: Drop double numbers as input format Ron Aaron <rambamist@gmail.com> - 2017-06-05 09:56 +0300
        Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 01:46 -0700
        Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-07 21:44 +1000
          Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-07 05:13 -0700
            Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-08 12:36 +1000
          Re: RFD: Drop double numbers as input format Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 07:33 -0700
            Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-08 12:34 +1000
              Re: RFD: Drop double numbers as input format Alex <alex@rivadpm.com> - 2017-06-08 09:55 +0100
                Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-11 17:22 +1000
          Re: RFD: Drop double numbers as input format hughaguilar96@gmail.com - 2017-06-08 17:13 -0700
    Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 02:18 -0700
    Re: RFD: Drop double numbers as input format "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-04 09:54 +0000
    Re: RFD: Drop double numbers as input format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-04 12:07 +0200
    Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-04 10:18 +0000
      Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 05:47 -0700
        Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-04 15:44 +0000
      Re: RFD: Drop double numbers as input format Matthias Trute <matthias.trute@gmail.com> - 2017-06-04 09:10 -0700
        Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-04 16:21 +0000
        Re: RFD: Drop double numbers as input format Coos Haak <htrofhc@gmail.com> - 2017-06-04 18:33 +0200
      Re: RFD: Drop double numbers as input format Bernd Paysan <bernd@net2o.de> - 2017-06-07 01:21 +0200
        Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 22:57 -0700
          Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-06 23:34 -0700
            Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-07 01:12 -0700
    Re: RFD: Drop double numbers as input format The Beez <the.beez.speaks@gmail.com> - 2017-06-07 02:38 -0700
    Re: RFD: Drop double numbers as input format JennyB <jennybrien@googlemail.com> - 2017-06-07 02:45 -0700
      Re: RFD: Drop double numbers as input format foxaudioresearch@gmail.com - 2017-06-08 18:34 -0700
        Re: RFD: Drop double numbers as input format Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-06-10 23:08 +0100
          Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-11 12:32 +0000
      Re: RFD: Drop double numbers as input format "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 18:07 +0000

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

#60374

Mark Wills <markwills1970@gmail.com> writes:
>On Monday, 5 June 2017 17:53:21 UTC+1, Cecil - k5nwa  wrote:
>> It's not just that a few languages use a decimal number but everyone 
>> that went to school was taught that 10.3 is a decimal number with an 
>> integer and a fraction part separated by a decimal point.
>
>In Britain, yes; in Eastern Europe you could use a comma and zero
>eyebrows would be raised.

In a world where Eastern Europe starts in Iceland, yes.  Actually, all
of Europe except Ireland, Malta, and the UK use a decimal comma (in
Switzerland and Croatia the decimal point also has some usage).  See

https://en.wikipedia.org/wiki/File:DecimalSeparator.svg

But that is irrelevant for the question at hand.  The Algol 60 idiocy
of not specifying the decimal separator has died out, and in Forth we
specify the decimal point as separator for FP numbers, like every
other programming language, and that's a good idea.

>Fixed-point and <# # #> work VERY well in Forth, and removing translation of strings containing a period into doubles would interfere with that whole
>paradigm.

Not in the least.  <# # #> work just as well if "1." is not recognized
as a double.

>Maybe we could adopt a character for floats?

We already have one: "1e" is a float.  That does not cut it, though,
and "~1" will not cut it, 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 2017: http://www.euroforth.org/ef17/

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

#60382

> 
> In a world where Eastern Europe starts in Iceland, yes.  Actually, all
> of Europe except Ireland, Malta, and the UK use a decimal comma (in
> Switzerland and Croatia the decimal point also has some usage).  See

We have decimal comma and dot separator for thousends: (in Romania)

1.000.000,00 is one million

However, due to the PC revolution and computing in general coming from
America, no one will complain if seeing 100.00 as one hundred, especially
if the number of digits after the dot are not three :)

OTOH, the 1,000 or 1,000,000 notation will be very confusing...

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

#60385

On Tuesday, 6 June 2017 11:08:35 UTC+1, Anton Ertl  wrote:
> We already have one: "1e" is a float.  That does not cut it, though,
> and "~1" will not cut it, either.
> 

Not when you're in HEX

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

#60402

On Tue, 06 Jun 2017 09:52:29 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Actually, all of Europe except Ireland, Malta, and the UK use
> a decimal comma (in Switzerland and Croatia the decimal point
> also has some usage).  See
> 
> https://en.wikipedia.org/wiki/File:DecimalSeparator.svg 

Thanks, I liked the Arabic? one best: "٫"  Perhaps this is not
ambiguous, and could replace the dot or comma..:)

Jan Coombs

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

#60394

On Tuesday, June 6, 2017 at 4:12:20 AM UTC-5, Mark Wills wrote:
> We're probably too far down the road to change it though. And would we want
> to? Fixed-point and <# # #> work VERY well in Forth, and removing translation of strings containing a period into doubles would interfere with that whole
> paradigm. I wouldn't want to throw that baby out with the bathwater.

More bathwater: that Forth isn't a bitrot language. There are so many
of those already. It'd be absurd to accept bitrot just to relieve a
little bit of tension that someone has with any language while they're
going through their very first tutorial in that language.

> Maybe we could adopt a character for floats?

123.456e <--

> ~123.456

Wait, was HEX your real concern? You input a lot of hexadecimal
literals alongside floating point numbers? When do you do that?
Does this happen so randomly in your code that a throwaway parsing
word would be a hassle?

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

#60403

On Tuesday, 6 June 2017 16:09:16 UTC+1, Julian Fondren  wrote:
> On Tuesday, June 6, 2017 at 4:12:20 AM UTC-5, Mark Wills wrote:
> > We're probably too far down the road to change it though. And would we want
> > to? Fixed-point and <# # #> work VERY well in Forth, and removing translation of strings containing a period into doubles would interfere with that whole
> > paradigm. I wouldn't want to throw that baby out with the bathwater.
> 
> More bathwater: that Forth isn't a bitrot language. There are so many
> of those already. It'd be absurd to accept bitrot just to relieve a
> little bit of tension that someone has with any language while they're
> going through their very first tutorial in that language.
> 
> > Maybe we could adopt a character for floats?
> 
> 123.456e <--
> 
> > ~123.456
> 
> Wait, was HEX your real concern? You input a lot of hexadecimal
> literals alongside floating point numbers? When do you do that?
> Does this happen so randomly in your code that a throwaway parsing
> word would be a hassle?

Who are you addressing here? Me?

No. Hex is not my concern. But 1e is a terrible example, and frankly is
great example of the confusion that can reign. Is 1e 30 base ten, or is
it a float? Who knows.

Is 3.141 a float, or is it three-thousand one-hundred and forty-one as
a double? Who knows.

~3.141

Aha. That's a float.

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

#60404

On Tuesday, June 6, 2017 at 1:51:20 PM UTC-5, Mark Wills wrote:
> But 1e is a terrible example, and frankly is
> great example of the confusion that can reign. Is 1e 30 base ten, or is
> it a float? Who knows.

Forth has BASE , therefore you're required to keep it in mind when you
read Forth code. In the absence of an explicit BASE , decimal's
assumed. I've never read 1e and not known what it is and I don't
believe that you have.

Last year, the mere fact that Perl has list and scalar contexts cost
me about 2 hours of development time. How many hours have you lost to
BASE ?

>
> Is 3.141 a float, or is it three-thousand one-hundred and forty-one as
> a double? Who knows.

In Forth, it's a double. It's never a float. Floats have 'e' in them.

Hey, if you're blind, is '' a float or is it a double? Who knows? What
if you get hit on the head while reading Forth and you can no longer
remember any of the lines of code that preceded the one you're looking
at? What does this line of code mean? Who knows! Does "DUP" mean
"duplicate the top item of the stack" or does it mean "compile the
behavior of duplicating the top item of the stack into the current
definition"? I have no idea! Context is hard!

>
> ~3.141
>
> Aha. That's

1. negative three thousand one hundred forty-one

2. even more pointless when your floats have an exponent anyway.

3. an ugly break in Forth syntax defended by "who knows" arguments.

4. not even the goal. 3.141 still isn't a float. Forth is still weird,
and its floats are still weird. Actually they're worse:

  # perl -le 'print 1e0'
  1

  # perl -le 'print ~1.0'
  18446744073709551614

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

#60583

On Sun, 4 Jun 2017 12:12:29 +0200 (CEST)
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:

> Not using BASE for floating point is a missed opportunity.
> Using E for exponent instead of e.g. ~ is a design error.

I've only just started to realise this, with some impending
float hardware to test.  I think this could be made to work:

    $1.7a /$10^ 0

    #147656.25 /#10^ -5
    
It needs DPL, and to scan ahead for the exponent.  For
punctuation 5 chars is a bit much, but the intent is clear,
though maybe a little too infixed perhaps? 

Should be able to grow if you have BigNums and BigFloats
installed. Would you use it?

Jan Coombs

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

#60311

mhx@iae.nl writes:
> Do you have an example where, in DECIMAL, a certain string
> could be both a double and a float?

Users of other languages might well fall over laughing when they
hear that in Forth, "3.14159" denotes a very large integer.

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

#60315

Paul Rubin wrote on 6/4/2017 8:05 PM:
> mhx@iae.nl writes:
>> Do you have an example where, in DECIMAL, a certain string
>> could be both a double and a float?
>
> Users of other languages might well fall over laughing when they
> hear that in Forth, "3.14159" denotes a very large integer.

Yes, especially the many places where Pi is equal to 3,141.59

-- 

Rick C

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

#60317

On Sunday, June 4, 2017 at 7:05:53 PM UTC-5, Paul Rubin wrote:
> mhx@iae.nl writes:
> > Do you have an example where, in DECIMAL, a certain string
> > could be both a double and a float?
> 
> Users of other languages might well fall over laughing when they
> hear that in Forth, "3.14159" denotes a very large integer.

Other languages are impoverished, therefore Forth is bad.

Forth is weird enough that Forth-without-doubles will still be weird.
It's a good thing that other languages have nothing weird about them,
like "hi" taking up 320 bytes of space, reverse("hi") returning "hi"
depending on how the containing function is called, not being able to
use the language itself at compile time, not having any kind of number
except for a float, not being able to use all available integer bits
provided by the machine, etc.

If the point is to reduce weirdness, the job isn't done with this RFD.
The job warrants a more complete plan.

There's actually no intent at all expressed by the RFD, but it's
obviously a "step 1" of a plan that at least includes a later "make
3.14159 a float". What's the point of that? You can have it as a float
right now with a parse, either individually or for an entire slab of
input. You can have it and also traditional infix expressions with
JvN's FORTRAN.f. When I was doing OpenGL I defined matrices out of
numbers that didn't even need a decimal point.

Actually, aren't you aware of how hard it sucks to deal with literals
and static data in other languages? They can't have neat
compile-time-only localized syntaxes appropriate for the input; the
best they can do is parse a string at runtime. Generally they don't,
and the suckage is just something they slog miserably through when it
comes up. In the following example I used copy&paste on the second
matrix because typing it out was too annoying.

Forth:

  create blah
    | 1 1 1 0 0
    | 1 1 0 0 0
    | 1 0 0 0 0
    | 0 0 0 0 0
    | 0 0 0 0 1

  room: hell
    | #####  In the distance
    | # @ #  you can hear
    | #####  Katy Perry
  room;

Typical language that nobody would fall over laughing at:

  blah = [
    [1.0, 1.0, 1.0, 0.0, 0.0],
    [1.0, 1.0, 0.0, 0.0, 0.0],
    [1.0, 0.0, 0.0, 0.0, 0.0],
    [0.0, 0.0, 0.0, 0.0, 0.0],  # is the next line's comma
    [0.0, 0.0, 0.0, 0.0, 1.0],  # an error? sometimes!
  ];

  room = expand_room_template([
    ["#####  In the distance"],
    ["# @ #  you can hear"],
    ["#####  Katy Perry"],
  ]);

You're given an opportunity to show off some of Forth's actual
advantages (including that it has doubles at all) and instead of doing
that you're turning around with the ball and trying to kick it into
a net that's a hundred miles off, when nobody else on either team
considers that net to be a goal. "Languages have to not be weird?",
Erlang asks while demanding the following syntax

  foo() ->
    bar(),
    case baz() of x -> quux(); y -> ok end.

where every single punctuation character must be just so (if you take
off the second line, the first line must now end in a dot instead of a
comma), instead of

  function foo() {
    bar();
    var result = baz();
    if (result === x) return quux();
    if (result === y) return ok;
    abort("baz() returned something unexpected")
  }

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

#60322

On Monday, June 5, 2017 at 5:26:58 AM UTC+2, Julian Fondren wrote:
> On Sunday, June 4, 2017 at 7:05:53 PM UTC-5, Paul Rubin wrote:
> > mhx@iae.nl writes:
[..] 
> There's actually no intent at all expressed by the RFD, but it's
> obviously a "step 1" of a plan that at least includes a later "make
> 3.14159 a float". What's the point of that? 
[..]

Indeed, an RfD with an agenda.

Actually, I am fine with "3.14159" being a float (although
"3.14159e" would be even better), but I do not agree
with sly machinations to get rid of ways to recognize  
double integers. 

-marcel

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

#60325

 
> Indeed, an RfD with an agenda.

Make Forth Great Again

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

#60320

On Monday, June 5, 2017 at 2:05:53 AM UTC+2, Paul Rubin wrote:
> mhx@iae.nl writes:
> > Do you have an example where, in DECIMAL, a certain string
> > could be both a double and a float?
> 
> Users of other languages might well fall over laughing when they
> hear that in Forth, "3.14159" denotes a very large integer.

Users of Forth might well fall over laughing when they
hear that in <some languages> "184467'440737'0'95505'92LLU"
probably denotes a very large integer.

-marcel

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

#60321

On 06/05/17 03:05, Paul Rubin wrote:
> mhx@iae.nl writes:
>> Do you have an example where, in DECIMAL, a certain string
>> could be both a double and a float?
> 
> Users of other languages might well fall over laughing when they
> hear that in Forth, "3.14159" denotes a very large integer.

In 8th, 3.14159 is a floating-point number as one would expect from
common usage in other languages and in general.  There are no "double
integers", just ints and bigints (and floats and bigfloats).

Conversions between representations are handled automatically, so "1 2.4
+" works as you would expect.

I did things that way, because I anticipated non-Forthers wanting to use
8th.  Good thing I did, too...

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

#60367

On Monday, 5 June 2017 01:05:53 UTC+1, Paul Rubin  wrote:
> mhx@iae.nl writes:
> > Do you have an example where, in DECIMAL, a certain string
> > could be both a double and a float?
> 
> Users of other languages might well fall over laughing when they
> hear that in Forth, "3.14159" denotes a very large integer.

Exactly. It was a bad idea in 1970, and it's even worse now!

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

#60430

Paul Rubin wrote:
> mhx@iae.nl writes:
> > Do you have an example where, in DECIMAL, a certain string
> > could be both a double and a float?
>
> Users of other languages might well fall over laughing when they
> hear that in Forth, "3.14159" denotes a very large integer.

You mean besides - having to work with a stack instead of variables,
coping with non-intuitive control structures, using different operators
for each datatype, and so on.

Makes you wonder how anyone learns Forth, right?  Yet newbies
get the hang of it in a few days.  What it tells me is that someone who
wants to learn, will.  Don't under-estimate the challenge and motivation
which results from seeing great Forth code producing results.
Dumbing down or reworking Forth in the hope it will pacify critics or
attract users would be a miscalculation.  It will simply confirm what
they already suspected - namely that Forth was broken to begin with.
Nobody is going to learn a broken language.

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

#60431

Am Mittwoch, 7. Juni 2017 13:44:09 UTC+2 schrieb HAA:
> Paul Rubin wrote:
> > mhx@iae.nl writes:
> > > Do you have an example where, in DECIMAL, a certain string
> > > could be both a double and a float?
> >
> > Users of other languages might well fall over laughing when they
> > hear that in Forth, "3.14159" denotes a very large integer.
> 
> You mean besides - having to work with a stack instead of variables,
> coping with non-intuitive control structures, using different operators
> for each datatype, and so on.
> 
> Makes you wonder how anyone learns Forth, right?  Yet newbies
> get the hang of it in a few days.  What it tells me is that someone who
> wants to learn, will.  Don't under-estimate the challenge and motivation
> which results from seeing great Forth code producing results.
> Dumbing down or reworking Forth in the hope it will pacify critics or
> attract users would be a miscalculation.  It will simply confirm what
> they already suspected - namely that Forth was broken to begin with.
> Nobody is going to learn a broken language.

I don't object because you are talking about motivated high-IQ programmers.

But IMO more important: there are more users of programs than programmers.
Normal users expect normal number syntax, pocket calculator like.

Now I cannot accept a number entry from user terminal "as is" with standard
Forth means. I have to write my own input routine from scratch.

But that's okay as long as you're a lone tinkerer, or when you are the
programmer and user in one person.

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

#60451

minforth@arcor.de wrote:
> Am Mittwoch, 7. Juni 2017 13:44:09 UTC+2 schrieb HAA:
> > Paul Rubin wrote:
> > > mhx@iae.nl writes:
> > > > Do you have an example where, in DECIMAL, a certain string
> > > > could be both a double and a float?
> > >
> > > Users of other languages might well fall over laughing when they
> > > hear that in Forth, "3.14159" denotes a very large integer.
> >
> > You mean besides - having to work with a stack instead of variables,
> > coping with non-intuitive control structures, using different operators
> > for each datatype, and so on.
> >
> > Makes you wonder how anyone learns Forth, right?  Yet newbies
> > get the hang of it in a few days.  What it tells me is that someone who
> > wants to learn, will.  Don't under-estimate the challenge and motivation
> > which results from seeing great Forth code producing results.
> > Dumbing down or reworking Forth in the hope it will pacify critics or
> > attract users would be a miscalculation.  It will simply confirm what
> > they already suspected - namely that Forth was broken to begin with.
> > Nobody is going to learn a broken language.
>
> I don't object because you are talking about motivated high-IQ programmers.
>
> But IMO more important: there are more users of programs than programmers.
> Normal users expect normal number syntax, pocket calculator like.
>
> Now I cannot accept a number entry from user terminal "as is" with standard
> Forth means. I have to write my own input routine from scratch.
>
> But that's okay as long as you're a lone tinkerer, or when you are the
> programmer and user in one person.

In those cases the 'user' won't be a forth programmer.  He/she will be running
an application whose input routine will be based on >FLOAT, NUMBER? etc.
which includes appropriate syntax checking.  Allowing a casual user access to
the forth text interpreter is very much "at your own risk" and something I would
avoid.

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

#60432

miercuri, 7 iunie 2017, 14:44:09 UTC+3, HAA a scris:
> Paul Rubin wrote:
> > mhx@iae.nl writes:
> > > Do you have an example where, in DECIMAL, a certain string
> > > could be both a double and a float?
> >
> > Users of other languages might well fall over laughing when they
> > hear that in Forth, "3.14159" denotes a very large integer.
> 
> You mean besides - having to work with a stack instead of variables,
> coping with non-intuitive control structures, using different operators
> for each datatype, and so on.
> 
> Makes you wonder how anyone learns Forth, right?  Yet newbies
> get the hang of it in a few days.  What it tells me is that someone who
> wants to learn, will.  Don't under-estimate the challenge and motivation
> which results from seeing great Forth code producing results.
> Dumbing down or reworking Forth in the hope it will pacify critics or
> attract users would be a miscalculation.  It will simply confirm what
> they already suspected - namely that Forth was broken to begin with.
> Nobody is going to learn a broken language.

Well, I may be dumbing down my forth... let's see:
I have only one kind of variables, like VALUEs or locals. Name is the
value, TO for store. In fact I renamed already TO as :=
This allows me to have commodities like += -= *= /=
Also, my atomic VAR HVAR CVAR DVAR different sizes are hidden, no need
to remember what @ or ! should you use (C@, etc..)
Locals are only two types, single and double. Doubles are especially 
usefull for dealing with strings, which are specified by addr,len double.
@ ! and co. will be used with pointers or buffers/tables/structures.
It's more obvious and less weird when using pointers. In forth when
you have a variable as a pointer, you should write:
variable ptr \ lets suppose a byte pointer
... ptr @ c@ ... x ptr @ c! ... 1 ptr +!
In my forth you simply write:
var ptr
... ptr c@ .... x ptr c! ... 1 += ptr
I also don't have 1+ 1- 2* etc. "words". The programmer will write
1 + 1 - 2 * etc. Well, I have those primitives but my compiler is 
smart enough to compile them when it encounters these sequences.
I have 'a' 'b' 'c' ascii literals, 0x01 hex literals like in C,
0b001 binary literals like in C, even 0o777 octals (not like in C)
the strings are escaped like in C (why not?) for example:
s" oh mama\n" or a zero terminated string s" oh bama\x00"

These are very simple things that a today programmer may expect
at least to not get a feeling it's using an alien language from Mars.
And the forth at the heart remains a very good one, really a classical
one. What's wrong in hiding the >R R@ return stack words from the user?
Or giving them the possibility to use locals if they are not confortable
with stack jugling? Or having the C '//' line comment instead of '\'?

Well, my forth is not standard anymore (in fact is far from being
standard for many other reasons). It was not in the first place,
and I have more advanced features like quotations or building words
(a replacement for create.. does>), but I don't expect the regular 
application programmer that will script my controllers in it to use
these features. Unless s/he is motivated indeed...

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

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

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

csiph-web