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

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

Just saw this - Description of Forth

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

Contents

  Just saw this - Description of Forth Steve Graham <solitary.wanderer52@gmail.com> - 2017-01-05 09:11 -0800
    Re: Just saw this - Description of Forth november.nihal@gmail.com - 2017-01-05 12:52 -0800
    Re: Just saw this - Description of Forth "HAA" <someone@microsoft.com> - 2017-01-07 12:08 +1100
      Re: Just saw this - Description of Forth Julian Fondren <julian.fondren@gmail.com> - 2017-01-06 18:09 -0800
        Re: Just saw this - Description of Forth "HAA" <someone@microsoft.com> - 2017-01-08 11:47 +1100
          Re: Just saw this - Description of Forth Julian Fondren <julian.fondren@gmail.com> - 2017-01-07 17:59 -0800
          Re: Just saw this - Description of Forth hughaguilar96@gmail.com - 2017-01-07 18:23 -0800
          Re: Just saw this - Description of Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-01-07 18:51 -1000
            Re: Just saw this - Description of Forth hughaguilar96@gmail.com - 2017-01-08 17:02 -0800
            Re: Just saw this - Description of Forth "HAA" <someone@microsoft.com> - 2017-01-10 10:38 +1100
              Re: Just saw this - Description of Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-09 17:35 -0800
                Re: Just saw this - Description of Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-01-09 18:32 -1000
                  Re: Just saw this - Description of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 04:17 -0600
                    Re: Just saw this - Description of Forth Alex <alex@rivadpm.com> - 2017-01-10 13:41 +0000
                      Re: Just saw this - Description of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 08:05 -0600
              Re: Just saw this - Description of Forth Alex <alex@rivadpm.com> - 2017-01-10 13:50 +0000
          Re: Just saw this - Description of Forth Alex <alex@rivadpm.com> - 2017-01-08 08:58 +0000
      Re: Just saw this - Description of Forth hughaguilar96@gmail.com - 2017-01-06 18:58 -0800
        Re: Just saw this - Description of Forth november.nihal@gmail.com - 2017-01-08 14:30 -0800
          Re: Just saw this - Description of Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-08 21:15 -0800
      Re: Just saw this - Description of Forth november.nihal@gmail.com - 2017-01-08 14:24 -0800

Page 1 of 2  [1] 2  Next page →

#53764 — Just saw this - Description of Forth

http://prog21.dadgum.com/8.html

[toc] | [next] | [standalone]

#53768

It was posted for all to read way back in 2007...

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

#53791

Steve Graham wrote:
> http://prog21.dadgum.com/8.html

He also says:

"I've finally decided that the whole Forth concept is too minimal in the modern world"

https://lawlessguy.wordpress.com/2016/12/04/an-interview-with-game-developer-james-hague/

Either he hasn't looked at ANS/200x and the mega applications it was intended
to facilitate - or he's seen the long list of excuses for why it hasn't.

I agree with him with the exception there will always be a place for a language
that's posited somewhere between assembler and the high-level library-based
systems needed to create mega apps.  In Forth it's possible to get a small app
up and running in less time than it takes a C programmer to plan his header files.
Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
future-proofing, it's getting the job done and out the door.  It doesn't need to
be Forth - any small language with few barriers (standards) and self-reliant
programmers will do.  Forth (read committees) need to be careful it doesn't
lose the only advantage and reason for existence it had.

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

#53794

On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
> Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> future-proofing, it's getting the job done and out the door.  It doesn't need to
> be Forth - any small language with few barriers (standards)

Couldn't roll my eyes any harder.

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

#53833

Julian Fondren wrote:
> On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
> > Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> > future-proofing, it's getting the job done and out the door.  It doesn't need to
> > be Forth - any small language with few barriers (standards)
>
> Couldn't roll my eyes any harder.

Which produced the greatest number of successes - Forth of the first two
decades, or Standard Forth of the latter two?

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

#53837

On Saturday, January 7, 2017 at 6:47:00 PM UTC-6, HAA wrote:
> Julian Fondren wrote:
> > On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
> > > Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> > > future-proofing, it's getting the job done and out the door.  It doesn't need to
> > > be Forth - any small language with few barriers (standards)
> >
> > Couldn't roll my eyes any harder.
> 
> Which produced the greatest number of successes - Forth of the first two
> decades, or Standard Forth of the latter two?

You can't answer your own question in a persuasive way, and the answer
wouldn't have anything to do with your original parenthesized
wisecrack.  You've got contact-stupidity from Hugh, who believes that
the only purpose of a Forth implementation is the production of cross
compilers. In a community as small as ours, trying to be an edgy
counter-signaling hipster has left you standing next to the lone
drunken idiot.  Gosh, you're so clever -- but if you wrote anything in
Forth, ever, you'd notice that standards weren't stopping you from
doing anything. Cleverness that can be defeated by running through a
tutorial is wasted energy.

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

#53838

On Saturday, January 7, 2017 at 5:47:00 PM UTC-7, HAA wrote:
> Julian Fondren wrote:
> > On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
> > > Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> > > future-proofing, it's getting the job done and out the door.  It doesn't need to
> > > be Forth - any small language with few barriers (standards)
> >
> > Couldn't roll my eyes any harder.
> 
> Which produced the greatest number of successes - Forth of the first two
> decades, or Standard Forth of the latter two?

The only success with Forth that I'm familiar with was the MiniForth --- it didn't conform to any standard --- even if Straight Forth were the "standard" of the whole Forth world, the only effect this would have on my MFX is that I would have been able to support literal numbers in TARG mode (because LITERAL would be vectored) and I wouldn't need any UR/Forth-specific code (I had only 2 or 3 small functions anyway, which isn't much).

All successes with Forth are in micro-controllers, and Straight Forth is for desktop-computers, so the issue of having a standard is moot in regard to being successful (any definition of "success" that involves making money) --- desktop-computer software is always given away for free (CompUSA and similar stores that sold shrink-wrapped boxes of disks went out of business about 20 years ago).

It is possible that a standard for micro-controllers could be developed --- it won't affect FPGA Forth processors --- it would only be for pretty generic (typically ARM) micro-controllers that need standardization for basic I/O chips such as UARTs.

HAA --- what is your involvement in Forth? Do you work with micro-controllers or desktop-computer software? What are you trying to accomplish?

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

#53841

On 1/7/17 2:47 PM, HAA wrote:
> Julian Fondren wrote:
>> On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
>>> Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
>>> future-proofing, it's getting the job done and out the door.  It doesn't need to
>>> be Forth - any small language with few barriers (standards)
>>
>> Couldn't roll my eyes any harder.
>
> Which produced the greatest number of successes - Forth of the first two
> decades, or Standard Forth of the latter two?

Hard to say. FORTH, Inc. has had ups and downs over this time, ranging 
from a few really big projects to a steady stream of smaller ones. I do 
know that in the late 80's it was becoming difficult for large companies 
to justify doing a project with a language that had no formal standard 
(i.e., recognized by one of the major standards bodies), and it became a 
great deal easier to overcome this hurdle once ANS Forth was approved in 
the early 90's. It also became a great deal easier to hire Forth 
programmers who knew Standard Forth and to step in to projects based on 
Forths other than FORTH, Inc. products since they tended to be much 
closer to the Standard, even when they weren't 100% compatible. So, I 
would definitely say the Standards have been good for Forth business.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#53875

On Saturday, January 7, 2017 at 9:51:52 PM UTC-7, Elizabeth D. Rather wrote:
> On 1/7/17 2:47 PM, HAA wrote:
> > Julian Fondren wrote:
> >> On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
> >>> Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> >>> future-proofing, it's getting the job done and out the door.  It doesn't need to
> >>> be Forth - any small language with few barriers (standards)
> >>
> >> Couldn't roll my eyes any harder.
> >
> > Which produced the greatest number of successes - Forth of the first two
> > decades, or Standard Forth of the latter two?
> 
> Hard to say. FORTH, Inc. has had ups and downs over this time, ranging 
> from a few really big projects to a steady stream of smaller ones. I do 
> know that in the late 80's it was becoming difficult for large companies 
> to justify doing a project with a language that had no formal standard 
> (i.e., recognized by one of the major standards bodies), and it became a 
> great deal easier to overcome this hurdle once ANS Forth was approved in 
> the early 90's. It also became a great deal easier to hire Forth 
> programmers who knew Standard Forth and to step in to projects based on 
> Forths other than FORTH, Inc. products since they tended to be much 
> closer to the Standard, even when they weren't 100% compatible. So, I 
> would definitely say the Standards have been good for Forth business.

You're a scam artist. 

You tell everybody that they need to take your novice class at Forth Inc. in order to qualify for employment. Either you teach it, or one of your sleazy sales-people such as Andrew Haley teaches it. You charge them hundreds of dollars for the class. Afterward the proud graduate says:
"I learned all about how PAD works! Now I know everything there is to know about string handling in ANS-Forth! Am I qualified to work as an ANS-Forth programmer?"
Then you say:
"Yes! You are a super-duper ANS-Forth programmer! Unfortunately, Forth Inc. doesn't have any job openings for programmers at the moment --- don't call us, we'll call you!"

When I called Forth Inc. (way back before I wrote the novice package) with bug reports, I never made contact with any programmer. I only spoke to sleazy salespeople who gave me the hard sell on how I had to pay $300 for an upgrade to version-3. I don't think Forth Inc. actually employees programmers --- all of your "programmers" are just sales people.

> Cheers,
> Elizabeth

You're an alcoholic aren't you?

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

#53908

Elizabeth D. Rather wrote:
> On 1/7/17 2:47 PM, HAA wrote:
> > Julian Fondren wrote:
> >> On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
> >>> Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> >>> future-proofing, it's getting the job done and out the door.  It doesn't need to
> >>> be Forth - any small language with few barriers (standards)
> >>
> >> Couldn't roll my eyes any harder.
> >
> > Which produced the greatest number of successes - Forth of the first two
> > decades, or Standard Forth of the latter two?
>
> Hard to say. FORTH, Inc. has had ups and downs over this time, ranging
> from a few really big projects to a steady stream of smaller ones. I do
> know that in the late 80's it was becoming difficult for large companies
> to justify doing a project with a language that had no formal standard
> (i.e., recognized by one of the major standards bodies), and it became a
> great deal easier to overcome this hurdle once ANS Forth was approved in
> the early 90's.

That's using an ANSI standard as a means of gaining formal recognition
(or losing an existing perception) in the hope it will secure financial benefit
for the Forth industry as a whole.  All the evidence is it either did not work
or possibly precipitated the route of Forth vendors from the market - which
often occurs when regulation is introduced.

All this is quite different, however, from saying Forth requires a universal
standard because of some innate need of the language e.g. its users are
dependent upon third party libraries.  The fact that Forth could have so
many 'standards' running simultaneously in the early days is evidence to
the contrary.  Let's not confuse the wish for a common standard and the
need for one.  None of this is to dismiss local standards which facilitate
operations and projects within a company or even between companies.

> It also became a great deal easier to hire Forth
> programmers who knew Standard Forth and to step in to projects based on
> Forths other than FORTH, Inc. products since they tended to be much
> closer to the Standard, even when they weren't 100% compatible.

Really?  What Forth programmer doesn't know ANS Forth which is a formal
description of 40 years of Forth?  Of greater concern would be a commercial
programmer who believed ANS Forth was all he needed to know.

"I would find examples of people using standard "portable" ANSI Forth routines
from libraries that were 10,000 times slower than the way I would do it."  J. Fox

> So, I
> would definitely say the Standards have been good for Forth business.
>
> Cheers,
> Elizabeth

There's barely two Forth vendors left.  Good (or not) for comp.lang.forth and those
who see themselves sitting on committees.  Forth seems to have learned nothing
from the last 23 years so here it goes again with yet another standard.  Sorry but
from where this old-timer sits, 200x has all the appearance of a robber going through
the pockets of the corpse that is ANS Forth looking for glory that evaporated long ago.

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

#53913

"HAA" <someone@microsoft.com> writes:
> That's using an ANSI standard as a means of gaining formal recognition
> (or losing an existing perception) in the hope it will secure
> financial benefit for the Forth industry as a whole.

That's a perfectly normal reason to standardize something.

> All the evidence is it either did not work or possibly precipitated
> the route of Forth vendors from the market

Maybe true, hard to tell.  In any case, an idea that turns out
afterwards to not work was not necessarily a bad idea when it was first
put in place.

It's more obvious to me that Forth's appropriate technical niche shrunk
as computers changed over the years, so non-standard Forths have also
fallen into disuse.  I don't see how not having a standard could help
that.

I don't personally care much about using Forth commercially or about
writing portable Forth code, but I still see ANS useful as a basis of
common understanding.  If I code something in gforth with the intention
of porting it to smaller Forth on an MCU, it's easier if the MCU Forth
at least somewhat resembles ANS even if some aspects differ.

>> It also became a great deal easier to hire Forth programmers who knew
>> Standard Forth 
> Really?  What Forth programmer doesn't know ANS Forth which is a formal
> description of 40 years of Forth?

You mean now?  Or when the ANS was first developed?  It's sure easier to
deal with a Forth reasonably similar to what you're used to, than a
completely idiosyncratic one that you might encounter if someone decided
to invent a Forth from scratch as part of a hardware project.

> "I would find examples of people using standard "portable" ANSI Forth
> routines from libraries that were 10,000 times slower than the way I
> would do it."  J. Fox

He was talking about running a software ANS implementation vs. running a
limited Forth on a hardware Forth chip.

> 200x has all the appearance of a robber going through the pockets of
> the corpse that is ANS Forth looking for glory that evaporated long
> ago.

Forth's days of growth are over, but it's perfectly reasonable for those
who use it to want to update the standard to reflect present-day
practices.

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

#53915

On 1/9/17 3:35 PM, Paul Rubin wrote:
> "HAA" <someone@microsoft.com> writes:
>> That's using an ANSI standard as a means of gaining formal recognition
>> (or losing an existing perception) in the hope it will secure
>> financial benefit for the Forth industry as a whole.
>
> That's a perfectly normal reason to standardize something.

Yes, in fact it's one of the main motivations for all the language 
standards.

>> All the evidence is it either did not work or possibly precipitated
>> the route of Forth vendors from the market

The casual vendors (people whose first goal in life is something other 
than Forth systems and projects) were pretty well gone by the tine the 
process started, as it became clear that making a serious business out 
of Forth took dedication. Ray Duncan, for example, was a doctor, and he 
opted out to do an advanced residency in neonatology. The remaining 
serious vendors were Creative Solutions (Don Colburn), MPE, Firmworks 
(Mitch Bradley, representing Open Boot for Sun) and FORTH, Inc. They 
stayed with the project throughout.

> Maybe true, hard to tell.  In any case, an idea that turns out
> afterwards to not work was not necessarily a bad idea when it was first
> put in place.
>
> It's more obvious to me that Forth's appropriate technical niche shrunk
> as computers changed over the years, so non-standard Forths have also
> fallen into disuse.  I don't see how not having a standard could help
> that.

Forth did not spread primarily because (a) it wasn't picked up by any 
noted academic groups; (b) it didn't receive enough publicity (articles 
written for the press, etc., and (c) in the 80's it acquired a 
reputation as being a hobbyist toy, largely due to FIG activities and 
promotions, and this was seen as a negative by many organizations.

> I don't personally care much about using Forth commercially or about
> writing portable Forth code, but I still see ANS useful as a basis of
> common understanding.  If I code something in gforth with the intention
> of porting it to smaller Forth on an MCU, it's easier if the MCU Forth
> at least somewhat resembles ANS even if some aspects differ.

Yes, that remains a major advantage.

>>> It also became a great deal easier to hire Forth programmers who knew
>>> Standard Forth
>> Really?  What Forth programmer doesn't know ANS Forth which is a formal
>> description of 40 years of Forth?
>
> You mean now?  Or when the ANS was first developed?  It's sure easier to
> deal with a Forth reasonably similar to what you're used to, than a
> completely idiosyncratic one that you might encounter if someone decided
> to invent a Forth from scratch as part of a hardware project.

The Standard definitely made it easier to hire Forth programmers, 
because they had a better shared understanding.

>> "I would find examples of people using standard "portable" ANSI Forth
>> routines from libraries that were 10,000 times slower than the way I
>> would do it."  J. Fox
>
> He was talking about running a software ANS implementation vs. running a
> limited Forth on a hardware Forth chip.

Jeff's company also suffered from a management decision to develop code 
by doing literal translations from C to Forth, leading to some 
excruciatingly bad Forth code.

>> 200x has all the appearance of a robber going through the pockets of
>> the corpse that is ANS Forth looking for glory that evaporated long
>> ago.
>
> Forth's days of growth are over, but it's perfectly reasonable for those
> who use it to want to update the standard to reflect present-day
> practices.

True.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#53927

Elizabeth D. Rather <erather@forth.com> wrote:
> On 1/9/17 3:35 PM, Paul Rubin wrote:
> 
>> I don't personally care much about using Forth commercially or about
>> writing portable Forth code, but I still see ANS useful as a basis of
>> common understanding.  If I code something in gforth with the intention
>> of porting it to smaller Forth on an MCU, it's easier if the MCU Forth
>> at least somewhat resembles ANS even if some aspects differ.
> 
> Yes, that remains a major advantage.

Indeed.  Otherwise, without specifying the specific Forth being used,
we wouldn't even agree what OR means.

Andrew.

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

#53931

On 1/10/2017 10:17, Andrew Haley wrote:
> Elizabeth D. Rather <erather@forth.com> wrote:
>> On 1/9/17 3:35 PM, Paul Rubin wrote:
>>
>>> I don't personally care much about using Forth commercially or about
>>> writing portable Forth code, but I still see ANS useful as a basis of
>>> common understanding.  If I code something in gforth with the intention
>>> of porting it to smaller Forth on an MCU, it's easier if the MCU Forth
>>> at least somewhat resembles ANS even if some aspects differ.
>>
>> Yes, that remains a major advantage.
>
> Indeed.  Otherwise, without specifying the specific Forth being used,
> we wouldn't even agree what OR means.
>
> Andrew.
>

Or NOT, which has been consigned to name limbo for decades, and will 
likely never get consensus.

-- 
Alex

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

#53933

Alex <alex@rivadpm.com> wrote:
> On 1/10/2017 10:17, Andrew Haley wrote:
>> Elizabeth D. Rather <erather@forth.com> wrote:
>>> On 1/9/17 3:35 PM, Paul Rubin wrote:
>>>
>>>> I don't personally care much about using Forth commercially or about
>>>> writing portable Forth code, but I still see ANS useful as a basis of
>>>> common understanding.  If I code something in gforth with the intention
>>>> of porting it to smaller Forth on an MCU, it's easier if the MCU Forth
>>>> at least somewhat resembles ANS even if some aspects differ.
>>>
>>> Yes, that remains a major advantage.
>>
>> Indeed.  Otherwise, without specifying the specific Forth being used,
>> we wouldn't even agree what OR means.
> 
> Or NOT, which has been consigned to name limbo for decades, and will 
> likely never get consensus.

Yeah.  :-) Every now and then I try to revive it.  I think the last
time was about five years ago:

> Elizabeth D. Rather <era...@forth.com> wrote:
> > 
> > This conversation encapsulates perfectly why NOT remains on the
> > banned list.
> 
> It does.  I just assumed that, 15 years on, any issue to do with
> legacy definitions of NOT was dead, so NOT could be resurrected to have
> its "obviously correct" meaning.  I was wrong, but I still miss being
> able to say  NOT IF .  Oh well, I suppose it's gone forever.

Andrew.

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

#53932

On 1/9/2017 23:38, HAA wrote:

> Sorry but
> from where this old-timer sits, 200x has all the appearance of a robber going through
> the pockets of the corpse that is ANS Forth looking for glory that evaporated long ago.

I know how the standard effort affects Hugh; he wants to belong very 
badly but can't bring himself to co-operate with people that disagree 
with him. He's always right, and compromise can never be achieved.

But you, I'm not so sure. How does this affect you?

-- 
Alex

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

#53844

On 1/8/2017 00:47, HAA wrote:
> Julian Fondren wrote:
>> On Friday, January 6, 2017 at 7:07:33 PM UTC-6, HAA wrote:
>>> Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
>>> future-proofing, it's getting the job done and out the door.  It doesn't need to
>>> be Forth - any small language with few barriers (standards)
>>
>> Couldn't roll my eyes any harder.
>
> Which produced the greatest number of successes - Forth of the first two
> decades, or Standard Forth of the latter two?
>

That's no more than an opinion in the form of a question.

-- 
Alex

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

#53795

On Friday, January 6, 2017 at 6:07:33 PM UTC-7, HAA wrote:
> I agree with him with the exception there will always be a place for a language
> that's posited somewhere between assembler and the high-level library-based
> systems needed to create mega apps.  In Forth it's possible to get a small app
> up and running in less time than it takes a C programmer to plan his header files.
> Maybe that's exaggerating (or not) but Forth isn't for endlessly planning and
> future-proofing, it's getting the job done and out the door.  It doesn't need to
> be Forth - any small language with few barriers (standards) and self-reliant
> programmers will do.  Forth (read committees) need to be careful it doesn't
> lose the only advantage and reason for existence it had.

I don't think that Forth has to be completely lacking in code-libraries and general-purpose data-structures the way that ANS-Forth and Forth-200x are. This is 1970s technology --- ANS-Forth is a toy language even by the standards of the 1990s --- ANS-Forth compared badly to QBASIC that was contemporary in 1994.

So long as you have quotations (that have access to the parent function's local variables) it is possible to support general-purpose data-structures. This is a good thing! Without general-purpose data-structures, Forth is too minimal for the modern world (or even for the 1990s).

OTOH, I don't think it is a good idea to have tagged data and GC --- that is too high-level and too inefficient --- we already have Scheme/Lisp and their derivatives for that.

My Straight Forth that I'm designing is a higher-level language than C (C lacks quotations and doesn't support general-purpose data-structures very well) but is a lower-level language than Scheme/Lisp (that are founded upon tagged data and GC) --- so, it is right in the middle --- it is roughly at the same level as Go which is an improved C (although it doesn't support parallel execution as done with the goroutines).

Straight Forth is oriented more toward numerical programming than Go is --- I have decided to change the design of Straight Forth now so that a "number" is defined as a ratio between two 64-bit integers --- I'm not aware of any language that supports this as a fundamental data type (languages such as Go can do this using structs and a rather complicated syntax; I think C++ can smooth out this syntax somewhat, but C++ itself is way more complicated than what I am designing).

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

#53870

[...]
> Straight Forth is oriented more toward numerical programming than Go is --- I have decided to change the design of Straight Forth now so that a "number" is defined as a ratio between two 64-bit integers --- I'm not aware of any language that supports this as a fundamental data type (languages such as Go can do this using structs and a rather complicated syntax; I think C++ can smooth out this syntax somewhat, but C++ itself is way more complicated than what I am designing).

I think both lisp and similar languages support ratios. 
https://en.wikipedia.org/wiki/Common_Lisp ( section 3 data types )

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

#53885

november.nihal@gmail.com writes:
> I think both lisp and similar languages support ratios. 
> https://en.wikipedia.org/wiki/Common_Lisp ( section 3 data types )

Scheme, Lisp, and symbolic math systems like Mathematica have rationals
as fundamental types.  Haskell has them as a library (Data.Ratio).

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web