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

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

Interesting article

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

Contents

  Interesting article Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-28 13:32 +0100
    Re: Interesting article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-28 13:06 +0000
      Re: Interesting article Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-07-29 14:49 -0700
        Re: Interesting article Elizabeth D Rather <erather@forth.com> - 2011-07-29 19:32 -0500
          Re: Interesting article Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-08-02 16:27 -0700
        Re: Interesting article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-30 11:41 +0000
          Re: Interesting article Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-08-02 16:38 -0700
          Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-02 17:47 -0700
            Re: Interesting article Peter Fälth <peter.falth@tin.it> - 2011-08-03 07:26 +0200
              Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-11 16:19 -0700
                Re: Interesting article Julian Fondren <ayrnieu@gmail.com> - 2011-08-11 22:57 -0500
                  Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-12 16:40 -0700
                    Re: Interesting article "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:59 -0400
                      Re: Interesting article Julian Fondren <ayrnieu@gmail.com> - 2011-08-14 13:13 -0500
                        Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-15 03:27 -0500
                          Re: Interesting article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-16 17:49 +0000
                            Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-17 02:47 -0500
                      Re: Interesting article "Elizabeth D. Rather" <erather@forth.com> - 2011-08-14 08:28 -1000
                      Re: Interesting article Nomen Nescio <nobody@dizum.com> - 2011-08-14 20:41 +0200
                        Re: Interesting article Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 13:01 -0700
                      Re: Interesting article Richard Owlett <rowlett@pcnetinc.com> - 2011-08-14 14:14 -0500
                      Re: Interesting article kenney@cix.compulink.co.uk - 2011-08-14 21:05 -0500
                      Re: Interesting article BruceMcF <agila61@netscape.net> - 2011-08-14 22:23 -0700
                      Re: Interesting article clvrmnky <spamtrap@clevermonkey.org> - 2011-10-23 02:13 +0000
                Re: Interesting article Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-13 12:29 -0700
                  Re: Interesting article "Elizabeth D. Rather" <erather@forth.com> - 2011-08-13 10:42 -1000
                  Re: Interesting article John Passaniti <john.passaniti@gmail.com> - 2011-08-13 13:50 -0700
                    Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-14 03:14 -0500
                    Re: Interesting article Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 02:12 -0700
                      Re: Interesting article John Passaniti <john.passaniti@gmail.com> - 2011-08-14 14:31 -0700
                  Re: Interesting article "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:58 -0400
      Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-29 19:18 -0700
        Re: Interesting article Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 04:13 -0500
        Re: Interesting article Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-31 10:07 +0000
          Re: Interesting article mhx@iae.nl (Marcel Hendrix) - 2011-07-31 11:31 +0200
            Re: Interesting article Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-31 22:24 +0000
    Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-28 10:02 -0500

Page 1 of 2  [1] 2  Next page →

#4464 — Interesting article

 From http://drdobbs.com/architecture-and-design/231002535

"Quality of implementation, however, is critically important in the 
satisfaction enjoyed by users of the language. It is the experiential 
difference between writing Ruby and JavaScript. The factor that, in my 
view, most affects this quality of implementation is the vision of the 
original creator. Where the vision is maintained by a single individual, 
quality thrives. Where committees determine features, quality declines 
inexorably: Each new release saps vitality from the language even as it 
appears to remedy past faults or provide new, awaited capabilities.

It is hard to argue that C (and separately, C++) have become more vital 
since control of their design passed from the original creators to 
committees. Likewise, Java since it migrated from the original design 
group to the JCP process. Language extension by committee roll call 
tends to result in functional but not inspiring changes. So the language 
gets no new lease on life and simply lives inside its original skin 
getting progressively fatter, more complex, and dragged down by otiose 
features."

The last sentence doesn't apply to Forth 200X - er does it?  :-)

-- 
Gerry

[toc] | [next] | [standalone]

#4465

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> From http://drdobbs.com/architecture-and-design/231002535
[about language standardization in general]
>So the language 
>gets no new lease on life and simply lives inside its original skin 
>getting progressively fatter, more complex, and dragged down by otiose 
>features."
>
>The last sentence doesn't apply to Forth 200X - er does it?  :-)

Maybe.  It's certainly much slower to get some feature adopted in
Forth200x than in a system that I maintain, and removing features is
pretty much a no-no; even if it is tried, it sometimes is not accepted
by the community (in particular, FORGET).  Sometimes things also
become factored better, though, reducing complexity (I think the
treatment of TO is such a case in Forth200x).

Anyway, if the result of the standardization process is too fat,
complex, and the standarized features are useless, people will stick
to the old standard or flock to slimmer, simpler, non-standard
systems; maybe machineForth, maybe Reva, HelForth, or RetroForth.  Or
maybe to a system like Factor that offers features that will never
make it into standard Forth.

Then people want to have this system in other environments and
implement something like it, and they want to port between these
systems, and for that they need another standard.  The cycle starts
again.

I don't know how the numbers of users of standard vs. non-standard
Forth systems develops, but I don't have the impression that there is
a significant movement away from standard to non-standard systems
because of the fat acquired through 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 2011: http://www.euroforth.org/ef11/

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

#4486

On Jul 28, 8:06 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
> > Fromhttp://drdobbs.com/architecture-and-design/231002535
>
> [about language standardization in general]
>
> >So the language
> >gets no new lease on life and simply lives inside its original skin
> >getting progressively fatter, more complex, and dragged down by otiose
> >features."
>
> >The last sentence doesn't apply to Forth 200X - er does it?  :-)
>
> Maybe.  It's certainly much slower to get some feature adopted in
> Forth200x than in a system that I maintain, and removing features is
> pretty much a no-no; even if it is tried, it sometimes is not accepted
> by the community (in particular, FORGET).  Sometimes things also
> become factored better, though, reducing complexity (I think the
> treatment of TO is such a case in Forth200x).
>
> Anyway, if the result of the standardization process is too fat,
> complex, and the standarized features are useless, people will stick
> to the old standard or flock to slimmer, simpler, non-standard
> systems; maybe machineForth, maybe Reva, HelForth, or RetroForth.  Or
> maybe to a system like Factor that offers features that will never
> make it into standard Forth.
>
> Then people want to have this system in other environments and
> implement something like it, and they want to port between these
> systems, and for that they need another standard.  The cycle starts
> again.
>
> I don't know how the numbers of users of standard vs. non-standard
> Forth systems develops, but I don't have the impression that there is
> a significant movement away from standard to non-standard systems
> because of the fat acquired through 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 2011:http://www.euroforth.org/ef11/


I think the classification of systems into two varieties, standard and
non-standard, is not particularly useful in practice. Maybe it is in
large software systems which are intended to be portable across many
platforms. But, Forth is generally not applied to such problems. In
practice, any "standard" system is going to implement features outside
of the standard, and "non-standard" systems come in a grey scale of
adherence to a given standard, e.g. Forth 94.

Krishna

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

#4491

On 7/29/11 4:49 PM, Krishna Myneni wrote:
> In practice, any "standard" system is going to implement features
> outside of the standard

Do you intend the quotes to imply that a system with additional features 
shouldn't be considered standard?  If so, I disagree.  The Forth 
standards present a *minimum* set of CORE features that programs are 
entitled to expect, and a list of WBNI options, but a system with CORE 
plus some selection of optional features is still fairly minimal, and 
the standard assumes that *every* "standard system" will have additional 
features of some sort.  I conjecture that a system without, for example, 
an assembler and interface to the host OS if there is one, wouldn't be 
terribly useful.

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]

#4555

On Jul 29, 7:32 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> On 7/29/11 4:49 PM, Krishna Myneni wrote:
>
> > In practice, any "standard" system is going to implement features
> > outside of the standard
>
> Do you intend the quotes to imply that a system with additional features
> shouldn't be considered standard?  If so, I disagree.  

No, I didn't mean to imply that, although I can see how you construed
that meaning from the use of the quotes. Additional features are going
to be necessary if the system is to be useful in a particular domain.

> ... The Forth
> standards present a *minimum* set of CORE features that programs are
> entitled to expect, and a list of WBNI options, but a system with CORE
> plus some selection of optional features is still fairly minimal, and
> the standard assumes that *every* "standard system" will have additional
> features of some sort.  I conjecture that a system without, for example,
> an assembler and interface to the host OS if there is one, wouldn't be
> terribly useful.
>

I certainly agree with your last statement! To paraphrase Julian
Noble's words, "any Forth system worthy of the name provides an
assembler".


> 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 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================


Krishna

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

#4499

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On Jul 28, 8:06=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> I don't know how the numbers of users of standard vs. non-standard
>> Forth systems develops, but I don't have the impression that there is
>> a significant movement away from standard to non-standard systems
>> because of the fat acquired through the standard.
...
>I think the classification of systems into two varieties, standard and
>non-standard, is not particularly useful in practice. Maybe it is in
>large software systems which are intended to be portable across many
>platforms. But, Forth is generally not applied to such problems. In
>practice, any "standard" system is going to implement features outside
>of the standard, and "non-standard" systems come in a grey scale of
>adherence to a given standard, e.g. Forth 94.

But the question is about whether the standardization effort just adds
useless fat, and in that context, such a classification can be useful.
There are systems like Gforth, SwiftForth and VFX that aim to be
standard, and there are systems like machineForth that do not.  

Sure, there are some systems that are not-standard that are relatively
close to the standard, and others that are farther away, but at least
have picked up some standardized features; and if we had any numbers,
we would have to worry about whether the two categories are sufficient
for our purpose or whether we should introduce additional categories
or maybe some continuous parameter (or several) for describing the
standards-affinity.  But since we don't have numbers, I think that a
more refined view is wasted effort, and worse, it would obscure the
point I was trying to make.

- 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 2011: http://www.euroforth.org/ef11/

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

#4556

On Jul 30, 6:41 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >On Jul 28, 8:06=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> I don't know how the numbers of users of standard vs. non-standard
> >> Forth systems develops, but I don't have the impression that there is
> >> a significant movement away from standard to non-standard systems
> >> because of the fat acquired through the standard.
> ...
> >I think the classification of systems into two varieties, standard and
> >non-standard, is not particularly useful in practice. Maybe it is in
> >large software systems which are intended to be portable across many
> >platforms. But, Forth is generally not applied to such problems. In
> >practice, any "standard" system is going to implement features outside
> >of the standard, and "non-standard" systems come in a grey scale of
> >adherence to a given standard, e.g. Forth 94.
>
> But the question is about whether the standardization effort just adds
> useless fat, and in that context, such a classification can be useful.
> There are systems like Gforth, SwiftForth and VFX that aim to be
> standard, and there are systems like machineForth that do not.  

I'm not arguing that a standard should not exist, just that the labels
of "standard" and "nonstandard", as applied to actual implementations,
don't generally give an indication of the degree of portability of
standard code to such systems. It is ridiculous to assert that a
standardization effort, in general, adds useless fat to existing
standards. That depends on the process and the judgement, and even
temperment of proposers, committee members, and the community. As far
as Forth 200x is concerned, despite my reservations for the necessity
of certain additions, I wouldn't come to the conclusion that the
standardization process has added useless fat. In fact, I believe the
process has been fairly restrained and conservative.

>
> Sure, there are some systems that are not-standard that are relatively
> close to the standard, and others that are farther away, but at least
> have picked up some standardized features; and if we had any numbers,
> we would have to worry about whether the two categories are sufficient
> for our purpose or whether we should introduce additional categories
> or maybe some continuous parameter (or several) for describing the
> standards-affinity.  But since we don't have numbers, I think that a
> more refined view is wasted effort, and worse, it would obscure the
> point I was trying to make.
>
> - 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 2011:http://www.euroforth.org/ef11/


Krishna

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

#4558

On Jul 30, 5:41 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> But the question is about whether the standardization effort just adds
> useless fat

The question is not about whether the standardization effort just adds
useless fat --- the question is about whether ANS-Forth is
fundamentally flawed or not.

As I said, my Forth will not be much fatter than ANS-Forth, and may
even be thinner. The primary differences will be at a fundamental
level. For one thing, as I said before, my system will be inherently a
cross-compiler; even when you are compiling to a desktop computer,
there will still be a distinction between HOST and TARG code ---
compile-time and run-time code won't all be jumbled together as done
in ANS-Forth.

Another difference, is that I will *require* code and data to be in
separate memory blocks on the target machine (not just allow this).
One of the big problems with ANS-Forth is that code and data is all
jumbled together. Separating them makes the system much simpler. For
example:

: CREATE
    HERE CONSTANT ;

When code and data are jumbled together, the above doesn't work
because CONSTANT builds a header at HERE, which is where we were
expecting the data to be. Also, the above doesn't work because DOES>
doesn't have anything to rebuild, as a constant is just a literal, but
that is another issue that I won't get into here.

The point that I'm making is that ANS-Forth is fundamentally flawed.
Even something simple such as requiring code and data to be separate,
can't be done because that would entail SwiftForth being upgraded,
which Forth Inc. isn't going to do --- Elizabeth Rather will howl that
there is legacy code somewhere that depends upon code and data being a
jumbled mess. Forth Inc. is only willing to allow some useless fat to
be added to ANS-Forth (implementing N>R and NR> should take about 5
minutes), but they aren't going to allow the fundamental problems to
be fixed.

You are totally focused on adding new words ("useless fat") to ANS-
Forth, but leaving the underlying problems in ANS-Forth set in stone.
You are not coming to grips with the fact that ANS-Forth is
fundamentally flawed. ANS-Forth was a failure in 1994, and Forth-200x
will be a failure in 201x or 202x or whenever it finally gets released
--- because nothing has changed since 1994.

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

#4559

Hugh Aguilar wrote:
> On Jul 30, 5:41 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> But the question is about whether the standardization effort just adds
>> useless fat
> 
> The question is not about whether the standardization effort just adds
> useless fat --- the question is about whether ANS-Forth is
> fundamentally flawed or not.
> 
> As I said, my Forth will not be much fatter than ANS-Forth, and may
> even be thinner. The primary differences will be at a fundamental
> level. For one thing, as I said before, my system will be inherently a
> cross-compiler; even when you are compiling to a desktop computer,
> there will still be a distinction between HOST and TARG code ---
> compile-time and run-time code won't all be jumbled together as done
> in ANS-Forth.
> 
> Another difference, is that I will *require* code and data to be in
> separate memory blocks on the target machine (not just allow this).
> One of the big problems with ANS-Forth is that code and data is all
> jumbled together. Separating them makes the system much simpler. For
> example:
> 
> : CREATE
>     HERE CONSTANT ;
> 
> When code and data are jumbled together, the above doesn't work
> because CONSTANT builds a header at HERE, which is where we were
> expecting the data to be. Also, the above doesn't work because DOES>
> doesn't have anything to rebuild, as a constant is just a literal, but
> that is another issue that I won't get into here.

My Forth does have separate memory areas for code and data (and headers)
It is also fully ANS compliant. The above definition of CREATE works
fine and produces identical code to the original CREATE. DOES> also
works perfectly with it! In a definition they are of course inlined!

BR
Peter Fälth

> 
> The point that I'm making is that ANS-Forth is fundamentally flawed.
> Even something simple such as requiring code and data to be separate,
> can't be done because that would entail SwiftForth being upgraded,
> which Forth Inc. isn't going to do --- Elizabeth Rather will howl that
> there is legacy code somewhere that depends upon code and data being a
> jumbled mess. Forth Inc. is only willing to allow some useless fat to
> be added to ANS-Forth (implementing N>R and NR> should take about 5
> minutes), but they aren't going to allow the fundamental problems to
> be fixed.
> 
> You are totally focused on adding new words ("useless fat") to ANS-
> Forth, but leaving the underlying problems in ANS-Forth set in stone.
> You are not coming to grips with the fact that ANS-Forth is
> fundamentally flawed. ANS-Forth was a failure in 1994, and Forth-200x
> will be a failure in 201x or 202x or whenever it finally gets released
> --- because nothing has changed since 1994.

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

#4749

On Aug 2, 11:26 pm, Peter Fälth <peter.fa...@tin.it> wrote:
> My Forth does have separate memory areas for code and data (and headers)
> It is also fully ANS compliant. The above definition of CREATE works
> fine and produces identical code to the original CREATE. DOES> also
> works perfectly with it! In a definition they are of course inlined!

You completely missed my point! I am aware that ANS-Forth *allows* a
Forth system to have separate code and data. ANS-Forth does not
*require* code and data to be separate however. Because of this, the
user must assume the worst case, which is that they are a jumbled
mess. Even if you know that the implementation that you are currently
using does have separate code and data, you can't take advantage of
this knowledge. If you write a program that depends upon code and data
being separate, your program will fail to work on an ANS-Forth
compliant system in which code and data are a jumbled mess.

The ANS-Forth standard is wishy-washy. It *allows* quite a lot, but it
doesn't make any firm statement about anything. As another example,
ANS-Forth allows the floating-point stack to be distinct from the
parameter stack, but it doesn't require this. If you want your program
to be ANS-Forth compliant, you have to assume the worst case, which is
that floats are on the parameter stack. As another example, ANS-Forth
allows the locals stack to be distinct from the return stack, but it
doesn't require this. If you want your program to be ANS-Forth
compliant, you have to assume the worst case, which is that locals are
on the return stack. You can't use >R and R> in a function that uses
locals, because this isn't going to work on every ANS-Forth compliant
system. Apparently the ANS-Forth committee were so focused on
supporting legacy code that they allowed both >R and R>, and locals,
because both were commonly used --- but they didn't notice that the
two were incompatible with each other!

I really see the ANS-Forth standard as being a reflection of Elizabeth
Rather's ultra-liberal philosophy. ANS-Forth allows a wide variety of
implementations, but this effectively makes the worst implementation
the standard. She also tolerates homosexuality here on
comp.lang.forth, but this effectively makes homosexuality the
standard. It is a mistake to tolerate these kinds of things at all,
because then they become the standard --- like letting the camel stick
his nose into the tent, and then pretty soon you get the whole camel.

In Straight Forth, I will *require* code and data to be separate and
the floating-point stack to be distinct. The user will not be required
to assume the worst-case scenario in which code and data are jumbled
together and floats are on the parameter stack. The user will not have
to pretend that it is the year 1979 and his program is running on an
8080 --- he can assume a more modern system.

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

#4754

Hugh Aguilar <hughaguilar96@yahoo.com> writes:

> On Aug 2, 11:26 pm, Peter Fälth <peter.fa...@tin.it> wrote:
>> My Forth does have separate memory areas for code and data (and headers)
>> It is also fully ANS compliant. The above definition of CREATE works
>> fine and produces identical code to the original CREATE. DOES> also
>> works perfectly with it! In a definition they are of course inlined!
>
> You completely missed my point! I am aware that ANS-Forth *allows* a
> Forth system to have separate code and data. ANS-Forth does not
> *require* code and data to be separate however. Because of this, the
> user must assume the worst case, which is that they are a jumbled
> mess. Even if you know that the implementation that you are currently
> using does have separate code and data, you can't take advantage of
> this knowledge. If you write a program that depends upon code and data
> being separate, your program will fail to work on an ANS-Forth
> compliant system in which code and data are a jumbled mess.

Just declare an environmental dependency.

> In Straight Forth, I will *require* code and data to be separate and
> the floating-point stack to be distinct. The user will not be required
> to assume the worst-case scenario in which code and data are jumbled
> together and floats are on the parameter stack. The user will not have
> to pretend that it is the year 1979 and his program is running on an
> 8080 --- he can assume a more modern system.

Here are two ways to create 'Straight Forth':

1. Create a list of environmental dependencies; name this list 'Straight
   Forth'; refer to this list in your Forth code.  Done.

   You might promote this list of enviranmental dependencies as
   reasonable and worthwhile.  You might also include a dependency on
   the (semantically) no-op word STRAIGHT-FORTH ,which your programs can
   begin with.  If you want to use particular Forth systems that however
   don't satisfy all of your dependencies, you can extend them to do so.
   .. which might involve some difficulty or some inefficiency, but
   nothing so difficult or so prone to inefficiency as -->

2. Throw ANS Forth completely away; invent your own Forth-like language;
   create your own implementation; write your own docs, tutorials, etc.

What is so hateful about #1?  What is so alluring about #2?

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

#4801

On Aug 11, 9:57 pm, Julian Fondren <ayrn...@gmail.com> wrote:
> Here are two ways to create 'Straight Forth':
>
> 1. Create a list of environmental dependencies; name this list 'Straight
>    Forth'; refer to this list in your Forth code.  Done.

Straight Forth isn't a subset of Forth-200x.

Straight Forth is inherently a cross-compiler. You must segregate your
code into HOST and TARG sections, with the HOST code executing at
compile-time and the TARG code executing at run-time. This is true
even if your host and targ processors are one and the same (which is
typical for desktop applications).

Every word has *two* versions of itself, in HOST and in TARG. A word
such as DUP will have a TARG version that duplicates the top item on
the stack, and a HOST version that compiles the TARG version. These
two versions have distinct xt values. For the most part, the HOST
version is automatically generated by the compiler. When you write a
TARG word, the compiler will automatically generate a HOST version
that compiles that TARG word. All of those xxx, words in my novice
package will not be necessary --- because the compiler will generate
them automatically. It is also possible for the programmer to write
HOST code manually (immediate words and defining words).

To a large extent, the whole state-smart ugliness of ANS-Forth will go
away. Functions don't have to test STATE to determine if they are
executing at compile-time or run-time. If the function is in HOST,
then it is executing at compile-time. If the function is in TARG, then
it is executing at run-time. Instead of having one word that handles
both compile-time and run-time (using a test of STATE followed by an
IF ELSE THEN construct), you have two words --- one in HOST and one in
TARG. This corresponds with the Forth philosophy that each word is
supposed to do one thing and only one thing (remember the cartoon in
"Thinking Forth" about the universal processor of word, data and
food?).

Many people (including you) have criticized the novice package for
having a long list of words whose only job is to compile another word.
For example:

: dup, ( -- )  \ runtime: a -- a a
    postpone dup ;

What the critics aren't realizing, is that I think this is dumb too! I
didn't have anything like this in MFX; the compiler just generated all
of these compiling words automatically. This ugly code is necessary in
ANS-Forth (and also Forth-200x), but it won't be necessary in Straight
Forth. Note, btw, that is is possible to POSTPONE these words --- see
FIELD in my novice package for an example of doubly-postponed code.

> 2. Throw ANS Forth completely away; invent your own Forth-like language;
>    create your own implementation; write your own docs, tutorials, etc.
>
> What is so hateful about #1?  What is so alluring about #2?

What is alluring about #2 is that doing so allows me to cut all ties
with Elizabeth Rather. This whole business of associating the Forth
community with homosexuality just absolutely disgusts me. I really
want to have nothing at all to do with Elizabeth Rather ever again ---
she is the soul of filth --- I hate her for what she has done to the
Forth community.

In case you didn't get it, I call my language "Straight Forth" to
distinguish it from Forth-200x, which I will refer to as "Gay Forth."
How is that for a marketing strategy? So long as Elizabeth Rather and
Bernd Payson continues to associate with John Passaniti, they will
continue to embarrass the Forth community and drive the Forthers into
my camp.

I am old enough (45) to remember a time when Forth was taken seriously
in the general programming world. In the late 1980s, Forth and C were
roughly comparable in their number of adherents. In those days,
assembly language (65c02 and Z80) was the dominant language, but
everybody knew that some high-level language would soon replace
assembly, and it was anybody's guess as to whether Forth or C would be
that language. Ten years later, Forth was completely dead and C was
dominant everywhere. Elizabeth Rather was personally responsible for
killing Forth. She, and Forth Inc., just embarrassed the Forth
community over and over again with their grotesque incompetence. If it
hadn't been for Elizabeth Rather routinely making the Forth community
look stupid, Forth could have become popular. Her new strategy of
associating Forth with homosexuality is just her latest and greatest
marketing blunder, but she has a long history of marketing blunders
behind her.

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

#4875

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:1f5417de-5702-4127-ac23-6c29f0e61695@t20g2000prf.googlegroups.com...
>
> I am old enough (45) to remember a time when Forth was taken seriously
> in the general programming world.
>

I'm old enough also.  Nobody knew of it.  Apparently, it was available for
some of the home built computers, perhaps IMSAI or Altair.  AFAIK, Forth
wasn't available for the personal home computers in the PC revolution such
as C64's, Apple II's, Timex Sinclair's.  Byte magazine was were people heard
of Forth.

> In the late 1980s, Forth and C were
> roughly comparable in their number of adherents.

Yeah, just about zero for both...

In the late '80's, the microprocessor explosion introduced everyone to:
BASIC, PASCAL, FORTRAN, and assembly for the host microprocessor.
BASIC and assembly were the most common.  MS controlled the market for
BASIC.  The MS version came installed on a number of them.  PASCAL and
FORTRAN were available.  As for FORTH? C?  They were unheard of.  C
wasn't done being standardized until 1989: PC revolution over.  C became
real
popular on PCs in the early '90's after the other microprocessor platforms
died.
There was an explosion of C compilers for the PC and numerous well written
books on it.  I seem to recall 5 versions at a CompUsa about '92.  IIRC,
diehards
for a number of those early platforms were still trying to get C onto them
in
the late '90's ...  That was long after SmallC came about and was ported to
quite a few micro's.

> In those days, assembly language (65c02 and Z80) was the dominant
> language,

Basically, true... although there were quite a number of other micro's.

> [...] but everybody knew that some high-level language would soon
> replace assembly, and it was anybody's guess as to whether Forth
> or C would be that language.

I don't recall that.

> Ten years later, Forth was completely dead and C was
> dominant everywhere.

If you remember, Forth experienced a number of major, very public failures.
It seemed cryptic.  It was rumored to be "write-only".  The Forth
microprocessors flopped.

I think that says more about C than Forth.  The C standards stripped C of
it's underlying hardware implementation just like Forth standards.  Forth is
much easier to implement than C, if you follow the early implementation
models: VM and ITC.  And, IIRC, Forth has been put on many more platforms
than C.  But, as I learn more and more Forth while implementing my
interpreter, I'm becoming more and more convinced that Forth's language is
not comparable to C in terms of power, funtionality and flexibility, at
least, so far.  If one must be an expert in Forth to "see" it's advantages
(if any) over C, there is no point in learning it.  In that case, by the
time one becomes an expert, they will have written mounds and mounds of
non-expert Forth, while a novice or mid-range C programmer will have written
mounds of acceptable code.  Modern Forth compilers may provide the
optimization levels that C has, but the language of Forth is lacking, IMO so
far.


Rod Pemberton

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

#4887

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:

> "Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
>> Ten years later, Forth was completely dead and C was
>> dominant everywhere.

This is ten years after "the late 80s"; i.e., the late 90s.  I was
learning to program in the late 90s, and only looked at Forth in
2000-2001 after someone made a disparaging reference to it in EFnet
#Perl, and I wondered if that was deserved.

It might be fun and self-indulgent to try to pin down when exactly Forth
'died', and who exactly was its killer, but I think it's more useful to
wonder if and how Forth has improved since the late 90s.  A quick pass
at this: I think people like I was are much more likely to hear about
it, and that the better systems for them to find are all better than
they were in the 90s, but what they'll find first are JonesForth or
Retro or Factor or a hundred 10%-implemented my-toy-Forths with cute
names like 'Fifth' and 'Finf is not Forth' in public source
repositories.

> I think that says more about C than Forth.  The C standards stripped C of
> it's underlying hardware implementation just like Forth standards.

F94 did this.  My understanding of F79 and F83 is that they were fairly
disasterous, with people walking away from Forth after F83 was so
incompatible with F79, and with both being too restrictive on system
implementations.

> But, as I learn more and more Forth while implementing my
> interpreter,

Ugh.  Look, you've been _lied_ to.  You learn Forth the way you learn
anything: by setting out to learn it, by reading tutorials and books, by
writing Forth code and getting people to tell you how awful it is, etc.

You do not "learn by implementing"; people who do that produce shit like
JonesForth.  If it's taking you a while to accomplish a goal with means
inapproriate to the accomplishment of that goal, you haven't been given
great insights into the experience of people who approach the goal with
actually appropriate means.

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

#4918

Julian Fondren <ayrnieu@gmail.com> wrote:

> F94 did this.  My understanding of F79 and F83 is that they were fairly
> disasterous, with people walking away from Forth after F83 was so
> incompatible with F79, and with both being too restrictive on system
> implementations.

And your understanding of -79 and -83 is based on what?  To
characterize either as "disastrous" is absurd.  Neither of them was
completely successful.  There were mistakes.  But both of them served
to reduce the amount of pointless divergence of Forth systems.

Andrew.

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

#4990

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
[Forth-79 and Forth-83]
> But both of them served
>to reduce the amount of pointless divergence of Forth systems.

Some people might disagree when it comes to NOT and PICK (and probably
a few others).

- 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 2011: http://www.euroforth.org/ef11/

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

#5004

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> [Forth-79 and Forth-83]
>> But both of them served to reduce the amount of pointless
>> divergence of Forth systems.
> 
> Some people might disagree when it comes to NOT and PICK (and probably
> a few others).

Would they?  Why?  The problem IIRC is that there was already some
divergence and the standard had to fall one way or the other.

Andrew.

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

#4890

On 8/14/11 3:59 AM, Rod Pemberton wrote:
> "Hugh Aguilar"<hughaguilar96@yahoo.com>  wrote in message
> news:1f5417de-5702-4127-ac23-6c29f0e61695@t20g2000prf.googlegroups.com...
>>
>> I am old enough (45) to remember a time when Forth was taken seriously
>> in the general programming world.
>>
>
> I'm old enough also.  Nobody knew of it.  Apparently, it was available for
> some of the home built computers, perhaps IMSAI or Altair.  AFAIK, Forth
> wasn't available for the personal home computers in the PC revolution such
> as C64's, Apple II's, Timex Sinclair's.  Byte magazine was were people heard
> of Forth.

The realm of "personal home computers" was in its infancy then. 
However, Forth was alive and well on minicomputers (e.g. PDP-11 and DG 
Novas) as well as the new microprocessors (8080, 6800, RCA Cosmac) 
targeted at embedded applications.

>> In the late 1980s, Forth and C were
>> roughly comparable in their number of adherents.
>
> Yeah, just about zero for both...

True for the world of personal computers, but Unix/C was spreading fast 
on larger minicomputers. PL/M (Intel) was promoted for a while for 
embedded micros, but Forth was very competitive.  This is the period in 
which I think if we had been able to afford more aggressive marketing 
Forth could have done well.

Basic and Pascal dominated personal computing until, as you say, the 
late 80's.

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]

#4894

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:

> AFAIK, Forth wasn't available for the personal home computers in the PC
> revolution such as C64's, Apple II's, Timex Sinclair's.  Byte magazine was
> were people heard of Forth.


BYTE August 1980:

Page 6: "Atari Inc. is using FORTH in two of its divisions"

Page 98: "Selected FORTH Vendors" shows implementations for Apple II with
Disk (Cap'n Software, San Fransisco), 8080, 8086, 6800, 1802, LSI-11, etc,
CP/M, TRS-80.

Page 104: KENYON Microsystems ad, iFORTH for 6809.

Page 157: ANCON implementations for 1802, 6502, 6800, 6809, 68k, 8080, 8085,
Z80, TI9900, etc.

Page 171: SIRIUS SYSTEMS ad for TFORTH for TRS-80.

Page 189: SuperSoft FORTH for CP/M Z80 or 8080

Page 208: Quality Software, Reseda, CA FORTH for Sorcerer

Page unknown (269 on inquiry card) 6502 FORTH $90 plus $4 s/h. Eric Rehnke

Page unknown (280 on inquiry card) tinyFORTH for TRS80 $49.95, Software
Farm, Reston VA.

BTW that issue of BYTE also shows implementation of several FORTH words in
IBM PL/I and S/360 assembler.

Some implementations of FORTH for the Commodore 64:
http://www.npsnet.com/danf/cbm/languages.html#FORTH

64 FORTH
Blazin' FORTH
C64 FORTH/97
C64 FORTH
Enhanced FORTH
FORTH
FORTH-64
geoFORTH
Master FORTH
Sixty FORTH
Super FORTH 64
Tiny FORTH
Tiny FORTH-64
Tri FORTH
UltraFORTH83
UNIFORTH
VIC FORTH
VolksForth
White Lightning

Other mentions found on web search "commodore 64 forth"

durexForth

Above list is just from a quick look at one issue and ten seconds of web
search. It appears there was no shortage of FORTH implementations for
popular PCs. I wasn't involved in PCs then but I did hear of FORTH. However
I got the wrong impression thinking it was another FOCAL or PROLOG type of
language for kids and I wasn't interested  in it. I didn't have a PC of any
kind so it didn't matter anyway.

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

#4897

On Aug 14, 7:41 pm, Nomen Nescio <nob...@dizum.com> wrote:
> "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote:
> > AFAIK, Forth wasn't available for the personal home computers in the PC
> > revolution such as C64's, Apple II's, Timex Sinclair's.  Byte magazine was
> > were people heard of Forth.
>
> BYTE August 1980:
>
> Page 6: "Atari Inc. is using FORTH in two of its divisions"
>
> Page 98: "Selected FORTH Vendors" shows implementations for Apple II with
> Disk (Cap'n Software, San Fransisco), 8080, 8086, 6800, 1802, LSI-11, etc,
> CP/M, TRS-80.
>
> Page 104: KENYON Microsystems ad, iFORTH for 6809.
>
> Page 157: ANCON implementations for 1802, 6502, 6800, 6809, 68k, 8080, 8085,
> Z80, TI9900, etc.
>
> Page 171: SIRIUS SYSTEMS ad for TFORTH for TRS-80.
>
> Page 189: SuperSoft FORTH for CP/M Z80 or 8080
>
> Page 208: Quality Software, Reseda, CA FORTH for Sorcerer
>
> Page unknown (269 on inquiry card) 6502 FORTH $90 plus $4 s/h. Eric Rehnke
>
> Page unknown (280 on inquiry card) tinyFORTH for TRS80 $49.95, Software
> Farm, Reston VA.
>
> BTW that issue of BYTE also shows implementation of several FORTH words in
> IBM PL/I and S/360 assembler.
>
> Some implementations of FORTH for the Commodore 64:http://www.npsnet.com/danf/cbm/languages.html#FORTH
>
> 64 FORTH
> Blazin' FORTH
> C64 FORTH/97
> C64 FORTH
> Enhanced FORTH
> FORTH
> FORTH-64
> geoFORTH
> Master FORTH
> Sixty FORTH
> Super FORTH 64
> Tiny FORTH
> Tiny FORTH-64
> Tri FORTH
> UltraFORTH83
> UNIFORTH
> VIC FORTH
> VolksForth
> White Lightning
>
> Other mentions found on web search "commodore 64 forth"
>
> durexForth
>
> Above list is just from a quick look at one issue and ten seconds of web
> search. It appears there was no shortage of FORTH implementations for
> popular PCs. I wasn't involved in PCs then but I did hear of FORTH. However
> I got the wrong impression thinking it was another FOCAL or PROLOG type of
> language for kids and I wasn't interested  in it. I didn't have a PC of any
> kind so it didn't matter anyway.

Indeed. Plenty of them for the popular UK home computers of the time
too - White Lightning was also available on the ZX Spectrum, and Psion
also produced a version of Forth for the Spctrum. HISOFT produced a
Forth for the Atari ST, there were versions for the Amiga, the Amstrad
CPC-464 - the list goes on.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web